You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(1) |
2
(18) |
3
(3) |
4
|
5
|
|
6
|
7
(2) |
8
(1) |
9
(5) |
10
(3) |
11
(17) |
12
(6) |
|
13
|
14
(3) |
15
(7) |
16
|
17
|
18
(4) |
19
(2) |
|
20
(1) |
21
(5) |
22
(10) |
23
(2) |
24
(11) |
25
(7) |
26
(8) |
|
27
(4) |
28
(5) |
29
|
30
(6) |
|
|
|
|
From: Ed M. <em...@fr...> - 2011-11-10 03:11:31
|
On Thu, Oct 06, 2011 at 09:05:08AM +0300, Mustafa Re??it ??ahin wrote: > Hello, > > > I am trying to run Valgrind on a FreeBSD 8.0 system with a Myri ethernet > card. My application uses libpcap to capture packets. Myri card has its > own snf ( Sniff )and libpcap libraries. I am able to run valgrind > without this card on my local machine. But when i run it on the system > with myri card i get errors and it does not work. The error states that > a function is not implemented. I guess the problem is about shared > libraries. My application uses shared libraries and the application > binary points right libraries as i check with ldd tool. There are some > warnings about system calls too. There is also an error about semaphores. Which version of the Valgrind port are you using? It sounds like the snf library uses a special interface to this Myri card, and the FreeBSD Valgrind port is unlikely to support it unless you're willing to implement the ioctl handler yourself. Syscall 405 is ksem_open which would explain the semaphore error. If it is not in the latest version of the port we'll put it on the roadmap to fix. -Ed |
|
From: Julian S. <js...@ac...> - 2011-11-09 19:12:08
|
> access is safe. This leads me to believe that Helgrind is not recognizing > the fact that the variables are thread-local. Possibly so; but it's too hard to diagnose without a specific test case. Please send a small program that shows the problem, or (better) file a bug report and attach the file to it. J |
|
From: David C. <dcc...@ac...> - 2011-11-09 18:49:17
|
On 11/9/2011 8:06 AM, Petr Pilař wrote: > Hello, > I came upon this weird behaviour, which is probably best described > using a sample, so here it is: http://codepad.org/7zSvMHGZ > I think this line alone sums it up pretty nicely: > "std::copy_backward(data + 2, data + size, data + size + 1);" (data_m > was declared as "int data_m[size + 1];") > > When I compile the code like so: g++ Test.cpp -ggdb3 and then run > valgrind with --leak-check=full on it, I get this: > http://codepad.org/1fMnYMbn > Again, the line "Source and destination overlap in memcpy(0x7ff00038c, > 0x7ff000388, 32)" pretty much sums it up. > > What am I doing wrong if anything? Is this caused by > std::copy_backward using memcpy and not memmove? Or is this a problem > on valgrinds's side? Or perhaps none of these? :) > > Best regards > Peter. According to http://www.cplusplus.com/reference/algorithm/copy_backward/ "If both ranges overlap in such a way that /result/ (which is the past-the-end element in the destination range) points to an element in the range /[first,last)/, the function copy() should be used instead." The third edition of Stroustrup's "The C++ Programming Language": "We use copy() when the sequences do not overlap, or if the end of the output sequence is in the input sequence. We use copy_backward() when the beginning of the output sequence is in the input sequence. In that way, no element is overwritten until it has been copied." Take a look at the equivalent template implementation in the above link. If in fact this is how the function is implemented in <algorithm>, the compiler could optimize it pretty heavily, and decide to use memcpy() to copy multiple elements at a time rather than implement the core of the loop inline copying single elements. Or maybe the g++ implementation of the template uses memcpy() directly. I bet that you would not get an error with copy_backward() if the number of bytes to be copied is less than 32 (e.g. size == 3, or size == 6 for 32-bit integers). The use of memcpy() this way when the sequences have a substantial amount of overlap is probably a g++ or library bug. What happens if you make your own local version of copy_backward() using the above model and use that? What is in the implementation of copy_backward() in <algorithm>? What version of g++ are you using? -- David Chapman dcc...@ac... Chapman Consulting -- San Jose, CA |
|
From: Paul A. <pa...@vi...> - 2011-11-09 18:40:59
|
Hello fellow Valgrind users! Could someone in the know please clarify the support of TLS in Valgrind/Helgrind? I am running Helgrind (version 3.7.0) on our code, which makes heavy use of TLS on GCC 4.5.1 with GLIBC 2.13. I am seeing a lot of what I believe are false positives, where a thread local variable is read on one thread and set on another "simultaneously". I don't see any possible way that there is contention since different threads are involved and by definition this access is safe. This leads me to believe that Helgrind is not recognizing the fact that the variables are thread-local. I have tried using VALGRIND_HG_DISABLE_CHECKING( ) on some of these variables, but even that seems to not work consistently. It's important to us for Valgrind tests to pass since we need to hand off the binaries to another group and they use Valgrind to validate their releases. Thanks in advance, Paul |
|
From: Petr P. <the...@gm...> - 2011-11-09 16:06:33
|
Hello, I came upon this weird behaviour, which is probably best described using a sample, so here it is: http://codepad.org/7zSvMHGZ I think this line alone sums it up pretty nicely: "std::copy_backward(data + 2, data + size, data + size + 1);" (data_m was declared as "int data_m[size + 1];") When I compile the code like so: g++ Test.cpp -ggdb3 and then run valgrind with --leak-check=full on it, I get this: http://codepad.org/1fMnYMbn Again, the line "Source and destination overlap in memcpy(0x7ff00038c, 0x7ff000388, 32)" pretty much sums it up. What am I doing wrong if anything? Is this caused by std::copy_backward using memcpy and not memmove? Or is this a problem on valgrinds's side? Or perhaps none of these? :) Best regards Peter. |
|
From: WAROQUIERS P. <phi...@eu...> - 2011-11-09 08:59:40
|
>Hi! > >I just compiled a 64bit Valgrind 3.7 on OS X 10.7 hoping to use it for >a new project. >Wanting to try it out, I ran it on a project I just started that just >allocated and de-allocated a matrix (correctly) and it said that there >are weird leaks somewhere in the ImageLoader namespace/class belonging >do /usr/bin/dyld. > >I've attached the leaky program and Valgrind's output below. To me it >seems that either OS X's dynamic linker leaks (which I find kind of >unlikely) or there is a bug in Valgrind. > >Thanks, >Dan In the trace you give, I only see reports of 'still reachable'. This means that there is memory which has been allocated, not de-allocated and Valgrind can still find pointers to this memory. When a process exits, in many cases, it is useless to spend cpu to free the memory you have in any case to keep till the end. So, this is why "leaks" are splitted in 3 kinds: * definitely leaked: not deallocated, not finding a pointer to it anywhere * possibly leaked: not deallocated, found a pointer pointing inside the block * still reachable: not deallocated, found a pointer pointer to the block. The manual describes in details the concept of definitely leaked/possibly leaked/still reachable. So, in summary, I suspect this is neither a bug in the OS X dynamic linker, nor in Valgrind. Just a subtility of the "leak concept". Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Dan-George F. <dan...@gm...> - 2011-11-08 22:18:04
|
Hi! I just compiled a 64bit Valgrind 3.7 on OS X 10.7 hoping to use it for a new project. Wanting to try it out, I ran it on a project I just started that just allocated and de-allocated a matrix (correctly) and it said that there are weird leaks somewhere in the ImageLoader namespace/class belonging do /usr/bin/dyld. I've attached the leaky program and Valgrind's output below. To me it seems that either OS X's dynamic linker leaks (which I find kind of unlikely) or there is a bug in Valgrind. Thanks, Dan |
|
From: Jeffrey W. <nol...@gm...> - 2011-11-07 13:37:30
|
Hi All, This looks like an awesome release. Great work. > This release adds support for > ARM/Android, ... Will Android be supporting Valgrind out of the box, or will it still require a custom ROM and kernel [1]? Jeff [1] https://blog.mozilla.com/jseward/2011/09/27/valgrind-on-android-current-status/ On Mon, Nov 7, 2011 at 5:12 AM, Julian Seward <js...@ac...> wrote: > > We are pleased to announce a new release of Valgrind, version 3.7.0, > available from http://www.valgrind.org. > > Valgrind is an open-source suite of simulation based debugging and > profiling tools. With the tools that come with Valgrind, you can > automatically detect many memory management and threading bugs, which > avoids hours of frustrating bug-hunting, and makes your code more > stable. You can also perform detailed time and space profiling to > help speed up and slim down your programs. > > 3.7.0 is a feature release with many significant improvements and the > usual collection of bug fixes. This release adds support for > ARM/Android, S390X/Linux and Mac OS X 10.7 (Lion). A GDB server has > been added, so you can now control your application from inside GDB > whilst it runs on Valgrind. There have been performance and > functionality improvements for the following tools: Helgrind, DRD, > Memcheck and exp-Ptrcheck. > > This release supports X86/Linux, AMD64/Linux, ARM/Linux, PPC32/Linux, > PPC64/Linux, S390X/Valgrind, ARM/Android (2.3.x), X86/Darwin and > AMD64/Darwin (Mac OS X 10.6 and 10.7). > > Our thanks to all those who contribute to Valgrind's development. > This release represents a great deal of time, energy and effort on the > part of many people. > > Happy (and productive) debugging and profiling, > > -- The Valgrind Developers |
|
From: Julian S. <js...@ac...> - 2011-11-07 10:17:01
|
We are pleased to announce a new release of Valgrind, version 3.7.0, available from http://www.valgrind.org. Valgrind is an open-source suite of simulation based debugging and profiling tools. With the tools that come with Valgrind, you can automatically detect many memory management and threading bugs, which avoids hours of frustrating bug-hunting, and makes your code more stable. You can also perform detailed time and space profiling to help speed up and slim down your programs. 3.7.0 is a feature release with many significant improvements and the usual collection of bug fixes. This release adds support for ARM/Android, S390X/Linux and Mac OS X 10.7 (Lion). A GDB server has been added, so you can now control your application from inside GDB whilst it runs on Valgrind. There have been performance and functionality improvements for the following tools: Helgrind, DRD, Memcheck and exp-Ptrcheck. This release supports X86/Linux, AMD64/Linux, ARM/Linux, PPC32/Linux, PPC64/Linux, S390X/Valgrind, ARM/Android (2.3.x), X86/Darwin and AMD64/Darwin (Mac OS X 10.6 and 10.7). Our thanks to all those who contribute to Valgrind's development. This release represents a great deal of time, energy and effort on the part of many people. Happy (and productive) debugging and profiling, -- The Valgrind Developers Release 3.7.0 (5 November 2011) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.7.0 is a feature release with many significant improvements and the usual collection of bug fixes. This release supports X86/Linux, AMD64/Linux, ARM/Linux, PPC32/Linux, PPC64/Linux, S390X/Linux, ARM/Android, X86/Darwin and AMD64/Darwin. Support for recent distros and toolchain components (glibc 2.14, gcc 4.6, MacOSX 10.7) has been added. * ================== PLATFORM CHANGES ================= * Support for IBM z/Architecture (s390x) running Linux. Valgrind can analyse 64-bit programs running on z/Architecture. Most user space instructions up to and including z10 are supported. Valgrind has been tested extensively on z9, z10, and z196 machines running SLES 10/11, RedHat 5/6m, and Fedora. The Memcheck and Massif tools are known to work well. Callgrind, Helgrind, and DRD work reasonably well on z9 and later models. See README.s390 for more details. * Preliminary support for MacOSX 10.7 and XCode 4. Both 32- and 64-bit processes are supported. Some complex threaded applications (Firefox) are observed to hang when run as 32 bit applications, whereas 64-bit versions run OK. The cause is unknown. Memcheck will likely report some false errors. In general, expect some rough spots. This release also supports MacOSX 10.6, but drops support for 10.5. * Preliminary support for Android (on ARM). Valgrind can now run large applications (eg, Firefox) on (eg) a Samsung Nexus S. See README.android for more details, plus instructions on how to get started. * Support for the IBM Power ISA 2.06 (Power7 instructions) * General correctness and performance improvements for ARM/Linux, and, by extension, ARM/Android. * Further solidification of support for SSE 4.2 in 64-bit mode. AVX instruction set support is under development but is not available in this release. * Support for AIX5 has been removed. * ==================== TOOL CHANGES ==================== * Memcheck: some incremental changes: - reduction of memory use in some circumstances - improved handling of freed memory, which in some circumstances can cause detection of use-after-free that would previously have been missed - fix of a longstanding bug that could cause false negatives (missed errors) in programs doing vector saturated narrowing instructions. * Helgrind: performance improvements and major memory use reductions, particularly for large, long running applications which perform many synchronisation (lock, unlock, etc) events. Plus many smaller changes: - display of locksets for both threads involved in a race - general improvements in formatting/clarity of error messages - addition of facilities and documentation regarding annotation of thread safe reference counted C++ classes - new flag --check-stack-refs=no|yes [yes], to disable race checking on thread stacks (a performance hack) - new flag --free-is-write=no|yes [no], to enable detection of races where one thread accesses heap memory but another one frees it, without any coordinating synchronisation event * DRD: enabled XML output; added support for delayed thread deletion in order to detect races that occur close to the end of a thread (--join-list-vol); fixed a memory leak triggered by repeated client memory allocatation and deallocation; improved Darwin support. * exp-ptrcheck: this tool has been reduced in scope so as to improve performance and remove checking that Memcheck does better. Specifically, the ability to check for overruns for stack and global arrays is unchanged, but the ability to check for overruns of heap blocks has been removed. The tool has accordingly been renamed to exp-sgcheck ("Stack and Global Array Checking"). * ==================== OTHER CHANGES ==================== * GDB server: Valgrind now has an embedded GDB server. That means it is possible to control a Valgrind run from GDB, doing all the usual things that GDB can do (single stepping, breakpoints, examining data, etc). Tool-specific functionality is also available. For example, it is possible to query the definedness state of variables or memory from within GDB when running Memcheck; arbitrarily large memory watchpoints are supported, etc. To use the GDB server, start Valgrind with the flag --vgdb-error=0 and follow the on-screen instructions. * Improved support for unfriendly self-modifying code: a new option --smc-check=all-non-file is available. This adds the relevant consistency checks only to code that originates in non-file-backed mappings. In effect this confines the consistency checking only to code that is or might be JIT generated, and avoids checks on code that must have been compiled ahead of time. This significantly improves performance on applications that generate code at run time. * It is now possible to build a working Valgrind using Clang-2.9 on Linux. * new client requests VALGRIND_{DISABLE,ENABLE}_ERROR_REPORTING. These enable and disable error reporting on a per-thread, and nestable, basis. This is useful for hiding errors in particularly troublesome pieces of code. The MPI wrapper library (libmpiwrap.c) now uses this facility. * Added the --mod-funcname option to cg_diff. * ==================== FIXED BUGS ==================== The following bugs have been fixed or resolved. Note that "n-i-bz" stands for "not in bugzilla" -- that is, a bug that was reported to us but never got a bugzilla entry. We encourage you to file bugs in bugzilla (http://bugs.kde.org/enter_valgrind_bug.cgi) rather than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX where XXXXXX is the bug number as listed below. 210935 port valgrind.h (not valgrind) to win32 to support client requests 214223 valgrind SIGSEGV on startup gcc 4.4.1 ppc32 (G4) Ubuntu 9.10 243404 Port to zSeries 243935 Helgrind: incorrect handling of ANNOTATE_HAPPENS_BEFORE()/AFTER() 247223 non-x86: Suppress warning: 'regparm' attribute directive ignored 250101 huge "free" memory usage due to m_mallocfree.c fragmentation 253206 Some fixes for the faultstatus testcase 255223 capget testcase fails when running as root 256703 xlc_dbl_u32.c testcase broken 256726 Helgrind tests have broken inline asm 259977 == 214223 (Valgrind segfaults doing __builtin_longjmp) 264800 testcase compile failure on zseries 265762 make public VEX headers compilable by G++ 3.x 265771 assertion in jumps.c (r11523) fails with glibc-2.3 266753 configure script does not give the user the option to not use QtCore 266931 gen_insn_test.pl is broken 266961 ld-linux.so.2 i?86-linux strlen issues 266990 setns instruction causes false positive 267020 Make directory for temporary files configurable at run-time. 267342 == 267997 (segmentation fault on Mac OS 10.6) 267383 Assertion 'vgPlain_strlen(dir) + vgPlain_strlen(file) + 1 < 256' failed 267413 Assertion 'DRD_(g_threadinfo)[tid].synchr_nesting >= 1' failed. 267488 regtest: darwin support for 64-bit build 267552 SIGSEGV (misaligned_stack_error) with DRD, but not with other tools 267630 Add support for IBM Power ISA 2.06 -- stage 1 267769 == 267997 (Darwin: memcheck triggers segmentation fault) 267819 Add client request for informing the core about reallocation 267925 laog data structure quadratic for a single sequence of lock 267968 drd: (vgDrd_thread_set_joinable): Assertion '0 <= (int)tid ..' failed 267997 MacOSX: 64-bit V segfaults on launch when built with Xcode 4.0.1 268513 missed optimizations in fold_Expr 268619 s390x: fpr - gpr transfer facility 268620 s390x: reconsider "long displacement" requirement 268621 s390x: improve IR generation for XC 268715 s390x: FLOGR is not universally available 268792 == 267997 (valgrind seg faults on startup when compiled with Xcode 4) 268930 s390x: MHY is not universally available 269078 arm->IR: unhandled instruction SUB (SP minus immediate/register) 269079 Support ptrace system call on ARM 269144 missing "Bad option" error message 269209 conditional load and store facility (z196) 269354 Shift by zero on x86 can incorrectly clobber CC_NDEP 269641 == 267997 (valgrind segfaults immediately (segmentation fault)) 269736 s390x: minor code generation tweaks 269778 == 272986 (valgrind.h: swap roles of VALGRIND_DO_CLIENT_REQUEST() ..) 269863 s390x: remove unused function parameters 269864 s390x: tweak s390_emit_load_cc 269884 == 250101 (overhead for huge blocks exhausts space too soon) 270082 s390x: Make sure to point the PSW address to the next address on SIGILL 270115 s390x: rewrite some testcases 270309 == 267997 (valgrind crash on startup) 270320 add support for Linux FIOQSIZE ioctl() call 270326 segfault while trying to sanitize the environment passed to execle 270794 IBM POWER7 support patch causes regression in none/tests 270851 IBM POWER7 fcfidus instruction causes memcheck to fail 270856 IBM POWER7 xsnmaddadp instruction causes memcheck to fail on 32bit app 270925 hyper-optimized strspn() in /lib64/libc-2.13.so needs fix 270959 s390x: invalid use of R0 as base register 271042 VSX configure check fails when it should not 271043 Valgrind build fails with assembler error on ppc64 with binutils 2.21 271259 s390x: fix code confusion 271337 == 267997 (Valgrind segfaults on MacOS X) 271385 s390x: Implement Ist_MBE 271501 s390x: misc cleanups 271504 s390x: promote likely and unlikely 271579 ppc: using wrong enum type 271615 unhandled instruction "popcnt" (arch=amd10h) 271730 Fix bug when checking ioctls: duplicate check 271776 s390x: provide STFLE instruction support 271779 s390x: provide clock instructions like STCK 271799 Darwin: ioctls without an arg report a memory error 271820 arm: fix type confusion 271917 pthread_cond_timedwait failure leads to not-locked false positive 272067 s390x: fix DISP20 macro 272615 A typo in debug output in mc_leakcheck.c 272661 callgrind_annotate chokes when run from paths containing regex chars 272893 amd64->IR: 0x66 0xF 0x38 0x2B 0xC1 0x66 0xF 0x7F == (closed as dup) 272955 Unhandled syscall error for pwrite64 on ppc64 arch 272967 make documentation build-system more robust 272986 Fix gcc-4.6 warnings with valgrind.h 273318 amd64->IR: 0x66 0xF 0x3A 0x61 0xC1 0x38 (missing PCMPxSTRx case) 273318 unhandled PCMPxSTRx case: vex amd64->IR: 0x66 0xF 0x3A 0x61 0xC1 0x38 273431 valgrind segfaults in evalCfiExpr (debuginfo.c:2039) 273465 Callgrind: jumps.c:164 (new_jcc): Assertion '(0 <= jmp) && ...' 273536 Build error: multiple definition of `vgDrd_pthread_cond_initializer' 273640 ppc64-linux: unhandled syscalls setresuid(164) and setresgid(169) 273729 == 283000 (Illegal opcode for SSE2 "roundsd" instruction) 273778 exp-ptrcheck: unhandled sysno == 259 274089 exp-ptrcheck: unhandled sysno == 208 274378 s390x: Various dispatcher tweaks 274447 WARNING: unhandled syscall: 340 274776 amd64->IR: 0x66 0xF 0x38 0x2B 0xC5 0x66 274784 == 267997 (valgrind ls -l results in Segmentation Fault) 274926 valgrind does not build against linux-3 275148 configure FAIL with glibc-2.14 275151 Fedora 15 / glibc-2.14 'make regtest' FAIL 275168 Make Valgrind work for MacOSX 10.7 Lion 275212 == 275284 (lots of false positives from __memcpy_ssse3_back et al) 275278 valgrind does not build on Linux kernel 3.0.* due to silly 275284 Valgrind memcpy/memmove redirection stopped working in glibc 2.14/x86_64 275308 Fix implementation for ppc64 fres instruc 275339 s390x: fix testcase compile warnings 275517 s390x: Provide support for CKSM instruction 275710 s390x: get rid of redundant address mode calculation 275815 == 247894 (Valgrind doesn't know about Linux readahead(2) syscall) 275852 == 250101 (valgrind uses all swap space and is killed) 276784 Add support for IBM Power ISA 2.06 -- stage 3 276987 gdbsrv: fix tests following recent commits 277045 Valgrind crashes with unhandled DW_OP_ opcode 0x2a 277199 The test_isa_2_06_part1.c in none/tests/ppc64 should be a symlink 277471 Unhandled syscall: 340 277610 valgrind crashes in VG_(lseek)(core_fd, phdrs[idx].p_offset, ...) 277653 ARM: support Thumb2 PLD instruction 277663 ARM: NEON float VMUL by scalar incorrect 277689 ARM: tests for VSTn with register post-index are broken 277694 ARM: BLX LR instruction broken in ARM mode 277780 ARM: VMOV.F32 (immediate) instruction is broken 278057 fuse filesystem syscall deadlocks 278078 Unimplemented syscall 280 on ppc32 278349 F_GETPIPE_SZ and F_SETPIPE_SZ Linux fcntl commands 278454 VALGRIND_STACK_DEREGISTER has wrong output type 278502 == 275284 (Valgrind confuses memcpy() and memmove()) 278892 gdbsrv: factorize gdb version handling, fix doc and typos 279027 Support for MVCL and CLCL instruction 279027 s390x: Provide support for CLCL and MVCL instructions 279062 Remove a redundant check in the insn selector for ppc. 279071 JDK creates PTEST with redundant REX.W prefix 279212 gdbsrv: add monitor cmd v.info scheduler. 279378 exp-ptrcheck: the 'impossible' happened on mkfifo call 279698 memcheck discards valid-bits for packuswb 279795 memcheck reports uninitialised values for mincore on amd64 279994 Add support for IBM Power ISA 2.06 -- stage 3 280083 mempolicy syscall check errors 280290 vex amd64->IR: 0x66 0xF 0x38 0x28 0xC1 0x66 0xF 0x6F 280710 s390x: config files for nightly builds 280757 /tmp dir still used by valgrind even if TMPDIR is specified 280965 Valgrind breaks fcntl locks when program does mmap 281138 WARNING: unhandled syscall: 340 281241 == 275168 (valgrind useless on Macos 10.7.1 Lion) 281304 == 275168 (Darwin: dyld "cannot load inserted library") 281305 == 275168 (unhandled syscall: unix:357 on Darwin 11.1) 281468 s390x: handle do_clone and gcc clones in call traces 281488 ARM: VFP register corruption 281828 == 275284 (false memmove warning: "Source and destination overlap") 281883 s390x: Fix system call wrapper for "clone". 282105 generalise 'reclaimSuperBlock' to also reclaim splittable superblock 282112 Unhandled instruction bytes: 0xDE 0xD9 0x9B 0xDF (fcompp) 282238 SLES10: make check fails 282979 strcasestr needs replacement with recent(>=2.12) glibc 283000 vex amd64->IR: 0x66 0xF 0x3A 0xA 0xC0 0x9 0xF3 0xF 283243 Regression in ppc64 memcheck tests 283325 == 267997 (Darwin: V segfaults on startup when built with Xcode 4.0) 283427 re-connect epoll_pwait syscall on ARM linux 283600 gdbsrv: android: port vgdb.c 283709 none/tests/faultstatus needs to account for page size 284305 filter_gdb needs enhancement to work on ppc64 284384 clang 3.1 -Wunused-value warnings in valgrind.h, memcheck.h 284472 Thumb2 ROR.W encoding T2 not implemented 284621 XML-escape process command line in XML output n-i-bz cachegrind/callgrind: handle CPUID information for Core iX Intel CPUs that have non-power-of-2 sizes (also AMDs) n-i-bz don't be spooked by libraries mashed by elfhack n-i-bz don't be spooked by libxul.so linked with gold n-i-bz improved checking for VALGRIND_CHECK_MEM_IS_DEFINED (3.7.0-TEST1: 27 October 2011, vex r2228, valgrind r12245) (3.7.0.RC1: 1 November 2011, vex r2231, valgrind r12257) (3.7.0: 5 November 2011, vex r2231, valgrind r12258) |
|
From: Dan K. <da...@ke...> - 2011-11-03 15:58:47
|
On Thu, Nov 3, 2011 at 7:48 AM, Peter Toft <pt...@li...> wrote:
> small twist to the code, then gcc -O2 -Wall finds nothing....
>
> See the comment -> run as "code -1"
>
> #include <stdio.h>
> #include <stdlib.h>
>
>
> /* Save as code.c compile "gcc -Wall -O2 o code code.c" and run as "code
> -1" */
> int main(int argc, char **argv)
> {
> int a[2],b[2],c[2],i;
>
> a[0] = 1; a[1] = 2;
> b[0] = 3; b[1] = 4;
> c[0] = 5; c[1] = 6;
>
>
> printf("Dummy print .... %i\n",c[0]);
> printf("argv[1] = %s\n",argv[1]);
> i = atoi(argv[1]);
> printf("index i = %i\n",i);
> printf("%i %i\n",b[i],a[i]);
> return 0;
> }
I recently found a real bug like this with valgrind
( see http://bugs.winehq.org/show_bug.cgi?id=25826,
in which the bug was caught because it ended up
causing an overlapping memcpy ). So it's worth
trying valgrind. And, luckily, Valgrind accidentally finds
something to complain about here (though it doesn't
point straight to the line in main() that causes it):
$ gcc -Wall -g -O2 -o code code.c
$ valgrind ./code -1
Dummy print .... 5
argv[1] = -1
index i = -1
Use of uninitialised value of size 4
at 0x4083B2B: _itoa_word (_itoa.c:195)
by 0x4087E55: vfprintf (vfprintf.c:1619)
by 0x412A054: __printf_chk (printf_chk.c:37)
2 68928292
- Dan
|
|
From: Peter T. <pt...@li...> - 2011-11-03 14:48:44
|
On Thu, 3 Nov 2011 11:09:34 +0000 (UTC), Julian Brown wrote:
> On
2011-11-01, Peter Toft wrote:
>> Hi all Try to find the errors in this
C/C++ snippet using valgrind: #include /* Save as code.c */ int
main(void) { int i=-1,a[2],b[2],c[2]; a[0] = 1; a[1] = 2; b[0] = 3; b[1]
= 4; c[0] = 5; c[1] = 6; printf("%i %in",b[i],a[i]); return 0; } Compile
using "gcc -o bla code.c -Wall" and check the code using
> FWIW, GCC
(4.6.1) finds this bug without trouble if you use -O2: $ gcc -O2 -Wall
loss.c -o loss loss.c: In function 'main': loss.c:5:22: warning:
variable 'c' set but not used [-Wunused-but-set-variable] loss.c:9:9:
warning: array subscript is below array bounds [-Warray-bounds]
loss.c:9:9: warning: array subscript is below array bounds
[-Warray-bounds] Some warning analyses are only run at higher
optimisation levels that -O0 (the default). Jules
------------------------------------------------------------------------------
RSA(R) Conference 2012 Save 0 by Nov 18 Register now
http://p.sf.net/sfu/rsa-sfdev2dev1 [2]
_______________________________________________ Valgrind-users mailing
list Val...@li... [3]
https://lists.sourceforge.net/lists/listinfo/valgrind-users [4]
small
twist to the code, then gcc -O2 -Wall finds nothing....
See the
comment -> run as "code -1"
#include
#include
/* Save as code.c
compile "gcc -Wall -O2 o code code.c" and run as "code -1" */
int
main(int argc, char **argv)
{
int a[2],b[2],c[2],i;
a[0] = 1; a[1] =
2;
b[0] = 3; b[1] = 4;
c[0] = 5; c[1] = 6;
printf("Dummy print ....
%in",c[0]);
printf("argv[1] = %sn",argv[1]);
i = atoi(argv[1]);
printf("index i = %in",i);
printf("%i %in",b[i],a[i]);
return 0;
}
--
Peter Toft, PhD
http://petertoft.dk
Links:
------
[1]
mailto:pt...@li...
[2] http://p.sf.net/sfu/rsa-sfdev2dev1
[3]
mailto:Val...@li...
[4]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Julian B. <ju...@pa...> - 2011-11-03 13:20:28
|
On 2011-11-01, Peter Toft <pt...@li...> wrote:
> Hi all
>
> Try to find the errors in this C/C++ snippet using valgrind:
>
> #include <stdio.h>
> /* Save as code.c */
> int main(void)
> {
> int i=-1,a[2],b[2],c[2];
> a[0] = 1; a[1] = 2;
> b[0] = 3; b[1] = 4;
> c[0] = 5; c[1] = 6;
> printf("%i %in",b[i],a[i]);
> return 0;
> }
>
> Compile using "gcc -o bla code.c -Wall" and check the code using
FWIW, GCC (4.6.1) finds this bug without trouble if you use -O2:
$ gcc -O2 -Wall loss.c -o loss
loss.c: In function ‘main’:
loss.c:5:22: warning: variable ‘c’ set but not used [-Wunused-but-set-variable]
loss.c:9:9: warning: array subscript is below array bounds [-Warray-bounds]
loss.c:9:9: warning: array subscript is below array bounds [-Warray-bounds]
Some warning analyses are only run at higher optimisation levels that -O0
(the default).
Jules
|
|
From: Baurzhan I. <ib...@ra...> - 2011-11-02 20:18:26
|
On Wed, Nov 02, 2011 at 08:01:34AM -0700, Dan Kegel wrote: > Don't forget about gcc's -fstack-protector-all option. That can find > a few things. I've already tried this with the OP's example, didn't help. With kind regards, Baurzhan. |
|
From: Dan K. <da...@ke...> - 2011-11-02 15:01:46
|
On Wed, Nov 2, 2011 at 6:55 AM, Baurzhan Ismagulov <ib...@ra...> wrote: > On Wed, Nov 02, 2011 at 09:42:41AM -0400, Jeffrey Walton wrote: >> > It worked for me for overflows (e.g., i = 2) but not underflows (with -1 >> > as in your original posting), regardless of how i has been set. That's >> > interesting, I wasn't aware of that. >> Did you try Clang with UBC Integer Overflow Checker)? I don't believe >> its undefined behavior per se, but IOC might be able to flag it since >> its also a dynamic checker. http://embed.cs.utah.edu/ioc/. > > Thanks for the hint, I'll have a look. Don't forget about gcc's -fstack-protector-all option. That can find a few things. |
|
From: Baurzhan I. <ib...@ra...> - 2011-11-02 13:56:16
|
On Wed, Nov 02, 2011 at 09:42:41AM -0400, Jeffrey Walton wrote: > > It worked for me for overflows (e.g., i = 2) but not underflows (with -1 > > as in your original posting), regardless of how i has been set. That's > > interesting, I wasn't aware of that. > Did you try Clang with UBC Integer Overflow Checker)? I don't believe > its undefined behavior per se, but IOC might be able to flag it since > its also a dynamic checker. http://embed.cs.utah.edu/ioc/. Thanks for the hint, I'll have a look. With kind regards, Baurzhan. |
|
From: Jeffrey W. <nol...@gm...> - 2011-11-02 13:42:47
|
Hi Baurzhan, On Wed, Nov 2, 2011 at 9:34 AM, Baurzhan Ismagulov <ib...@ra...> wrote: > On Wed, Nov 02, 2011 at 01:55:50PM +0100, Peter Toft wrote: >> > There is also mudflap of gcc which claims to catch exactly this sort >> > of errors. >> >> I might be mistaking here.... but if the value if "i" is set from argv >> or alike then mudflap cannot help on this problem. > > It worked for me for overflows (e.g., i = 2) but not underflows (with -1 > as in your original posting), regardless of how i has been set. That's > interesting, I wasn't aware of that. Did you try Clang with UBC Integer Overflow Checker)? I don't believe its undefined behavior per se, but IOC might be able to flag it since its also a dynamic checker. http://embed.cs.utah.edu/ioc/. Jeff |
|
From: Baurzhan I. <ib...@ra...> - 2011-11-02 13:34:31
|
On Wed, Nov 02, 2011 at 01:55:50PM +0100, Peter Toft wrote: > > There is also mudflap of gcc which claims to catch exactly this sort > > of errors. > > I might be mistaking here.... but if the value if "i" is set from argv > or alike then mudflap cannot help on this problem. It worked for me for overflows (e.g., i = 2) but not underflows (with -1 as in your original posting), regardless of how i has been set. That's interesting, I wasn't aware of that. With kind regards, Baurzhan. |
|
From: Peter T. <pt...@li...> - 2011-11-02 12:55:57
|
On Wed, 2 Nov 2011 13:20:55 +0100, Baurzhan Ismagulov wrote:
> On
Tue, Nov 01, 2011 at 11:33:20PM +0100, Peter Toft wrote:
>> int
i=-1,a[2],b[2],c[2]; a[0] = 1; a[1] = 2; b[0] = 3; b[1] = 4; c[0] = 5;
c[1] = 6; printf("%i %in",b[i],a[i]);
> ...
>
>> Are there
supplementary tools I should check?
> There is also mudflap of gcc which
claims to catch exactly this sort of errors. It isn't perfect, either.
With kind regards, Baurzhan.
I might be mistaking here.... but if the
value if "i" is set from argv or alike then mudflap cannot help on this
problem.
Best
Peter
--
Peter Toft, PhD
http://petertoft.dk
|
|
From: Baurzhan I. <ib...@ra...> - 2011-11-02 12:35:14
|
On Tue, Nov 01, 2011 at 11:33:20PM +0100, Peter Toft wrote:
> int i=-1,a[2],b[2],c[2];
> a[0] = 1; a[1] = 2;
> b[0] = 3; b[1] = 4;
> c[0] = 5; c[1] = 6;
> printf("%i %in",b[i],a[i]);
...
> Are there supplementary tools I should check?
There is also mudflap of gcc which claims to catch exactly this sort of
errors. It isn't perfect, either.
With kind regards,
Baurzhan.
|
|
From: Peter T. <pt...@li...> - 2011-11-02 11:41:00
|
On Wed, 2 Nov 2011 11:56:58 +0100, Julian Seward wrote:
> On
Wednesday, November 02, 2011 09:31:18 am Peter Toft wrote:
>
>>
#include /* Save as code.c */ int main(void) { int i=-1,a[2],b[2],c[2];
a[0] = 1; a[1] = 2; b[0] = 3; b[1] = 4; c[0] = 5; c[1] = 6; printf("%i
%in",b[i],a[i]); return 0; }
>
>> I cannot see exp-sgcheck catching
anything (compiled from the SVN version) :/
> Yeah. That's because of
the limitations of how sgcheck works. Have a look at
http://www.valgrind.org/docs/manual/pc-manual.html#pc-manual.limitations
[1] and specifically at the 4th bullet point ("Stack checks: It follows
...") If you change your test program so that each memory referencing
insn iterates over an array and goes out of bounds, then it should get
spotted. But that's not the case here: each memory referencing insn (for
the various arrays) is only used once and so there's no opportunity for
the tool to infer which array each instruction is probably "supposed" to
access. (That probably won't make much sense until you read the URL
above ..) J
Naturally I can easily redo that code so valgrind catches
the bug-type I show you e.g. by declaring the arrays via pointers and
allocating those with malloc/free, however I often find code from
Joe-average-designer or random-X-program, that the code style can
contain a mix of the errors valgrind currently is good at catching and
the ones I try to high-light in this mail-thread.
I would really like
to have an extended valgrind-workmode where the user can augment even
the compile process and/or link process, so the flow of valgrind could
also catch the mentioned kind of error.
Best
--
Peter Toft,
PhD
http://petertoft.dk
Links:
------
[1]
http://www.valgrind.org/docs/manual/pc-manual.html#pc-manual.limitations
|
|
From: Julian S. <js...@ac...> - 2011-11-02 10:57:14
|
On Wednesday, November 02, 2011 09:31:18 am Peter Toft wrote:
> #include /* Save as code.c */
> int main(void) { int
> i=-1,a[2],b[2],c[2];
> a[0] = 1; a[1] = 2; b[0] = 3; b[1] = 4; c[0] = 5;
> c[1] = 6;
> printf("%i %in",b[i],a[i]); return 0;
> }
> I cannot see exp-sgcheck catching anything (compiled from the SVN
> version) :/
Yeah. That's because of the limitations of how sgcheck works. Have a
look at
http://www.valgrind.org/docs/manual/pc-manual.html#pc-manual.limitations
and specifically at the 4th bullet point ("Stack checks: It follows ...")
If you change your test program so that each memory referencing insn
iterates over an array and goes out of bounds, then it should get
spotted. But that's not the case here: each memory referencing insn
(for the various arrays) is only used once and so there's no opportunity
for the tool to infer which array each instruction is probably "supposed"
to access. (That probably won't make much sense until you read the
URL above ..)
J
|
|
From: Tom H. <to...@co...> - 2011-11-02 10:19:24
|
On 02/11/11 10:18, Peter Toft wrote: > I cannot see tha that other two tools do much better on this kind of > coding problem. I see the same, which did surprise me a little. > Maybe that I do not give valgrind sufficient amount of options. Can you > comment? Well it is an experimental tool (hence the exp- prefix) so it isn't expected to be perfect yet. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Tom H. <to...@co...> - 2011-11-02 08:34:37
|
On 02/11/11 07:41, Peter Toft wrote: > Actually in the future I would wish that memcheck could be extended so > it could catch it - even if it would cost compile-time changes. > > Valgrind is a great tool, but its user-value would increase quite a bit, > if it could catch a bit more (e.g. like my example). As we have explained, valgrind does support it, just in a different tool. There are performance reasons for keeping them separate because they operate in completely different ways. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Tom H. <to...@co...> - 2011-11-02 08:33:29
|
On 02/11/11 07:36, Peter Toft wrote: > Valgrind _does_ point to the problematic area - but finds the problem as > a unitialized values. Quite possible, depending on how the compiler chooses to arrange the stack. > I did not know that the values I get with my example is different from > 32 bit to 64 bit systems. > > Apparently the memory stacking works differently. Anyone who can explain > this? As I say, it's entirely up the compiler what order it places the variables in on the stack, and what padding it puts between them. That may well, for example, vary in 32 vs 64 bit mode in order to get the correct alignment of variables. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Peter T. <pt...@li...> - 2011-11-02 08:31:26
|
On Wed, 02 Nov 2011 08:41:25 +0100, Peter Toft wrote:
> On Wed,
02 Nov 2011 00:32:44 +0000, Tom Hughes wrote:
>
>> On 01/11/11 22:33,
Peter Toft wrote:
>>
>>> Try to find the errors in this C/C++ snippet
using valgrind: #include /* Save as code.c */ int main(void) { int
i=-1,a[2],b[2],c[2]; a[0] = 1; a[1] = 2; b[0] = 3; b[1] = 4; c[0] = 5;
c[1] = 6; printf("%i %in",b[i],a[i]); return 0; } Compile using "gcc -o
bla code.c -Wall" and check the code using "valgrind ./bla". Valgrind
finds nothing even though I index a[-1] and b[-1] - not good...
>>
That's because you're using the wrong tool. You're using the default
memcheck tool, which will tell you about any use of uninitialised data,
but because you are dealing with stack variables you have no gaps
between your variables (with heap memory valgrind would ensure there was
a gap) so an out of bounds access is likely to just access an adjacent
(and defined) variable. This should all be explained in the manual,
which you probably want to read to understand what memcheck will and
won't find. The tool that might find this problem is exp-ptrcheck (in
the released version) or exp-sgcheck (in the svn code). That
specifically looks for out of bounds access to stack variables by using
the debug information to discover the bounds. Tom
>
> He he - I knew
perfectly well, that I could not find this problem with the memcheck
tool, but wanted your input on how to cope with those problems.
>
>
Actually in the future I would wish that memcheck could be extended so
it could catch it - even if it would cost compile-time changes.
>
>
Valgrind is a great tool, but its user-value would increase quite a bit,
if it could catch a bit more (e.g. like my example).
>
> Would it
possible to make this?
>
> I will check exp-sgcheck in a sec - thanx
Tom!
I cannot see exp-sgcheck catching anything (compiled from the SVN
version) :/
Best
/pto
--
Peter Toft, PhD
http://petertoft.dk
|