|
From: Dennis W. <dw...@ma...> - 2009-06-04 13:16:33
Attachments:
signature.asc
|
Hi list, let me start stating the obvious: valgrind is awesome and has helped me to spot quite a few nasty things in my code - thank you for your commitment in creating and improving this incredibly helpful tool! I have just updated to valgrind 3.4.1 compiled from source to find some odd behaviour of my program (which now turned out to be a libc bug). Anyway, the matter at hand really is that valgrind trashes my console with strange characters, some of them proper ascii ones, some of them non-printable or control characters. 3.3.1 did not do this, but otherwise produced pretty much the same output. I'll gladly give you a taste (though I highly doubt it will be rendered correctly for you) There you go: --941206317-Æ Memcheck, a memory error detector --941206317-Æ Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. --941206317-Æ Using LibVEX rev 1884, a library for dynamic binary translation. --941206317-Æ Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. --941206317-Æ Using valgrind-3.4.1, a dynamic binary instrumentation framework. --941206317-Æ Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. --941206317-Æ For more details, rerun with: -v --941206317-Æ (each ..17- is followed by a Danish(?) AE-character) [...] 240000000( Warning: set address range perms: large range [0x8bd2028, 0x170b3c28) (defined) (the 240... is bracketed by something that is rendered as the outline of a square in bash) [...] Ì1652879052h Invalid free() / delete / delete[] Z67227738 at 0x401D05A: free (vg_replace_malloc.c:323) œ69949373 by 0x42B57BD: (within /lib/tls/i686/cmov/libc-2.3.6.so) q69947249 by 0x42B4F71: (within /lib/tls/i686/cmov/libc-2.3.6.so) 67212574 by 0x401951E: _vgnU_freeres (vg_preloaded.c:60) 69434883 by 0x4237E03: _Exit (in /lib/tls/i686/cmov/libc-2.3.6.so) ¯68939439 by 0x41BEEAF: (below main) (in /lib/tls/i686/cmov/libc-2.3.6.so) -1640719376-õ Address 0x4184550 is not stack'd, malloc'd or (recently) free'd 1 1 ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 21 from 1) 0 malloc/free: in use at exit: 0 bytes in 0 blocks. 0 malloc/free: 11,744 allocs, 11,745 frees, 360,837,120 bytes allocated. 1 For counts of detected errors, rerun with: -v 1 All heap blocks were freed -- no leaks are possible. Ok, this even renders absurdly in Thunderbird, but I hope you get the gist. Repeated runs of valgrind produce the same weird characters, i.e. it is deterministic instead of random stuff. Since this behaviour starts right from the beginning, I conclude that it is not (at least entirely) due to potential memory corruption by my code - right? I'm running this in GNU bash, version 3.1.17(1)-release (i486-pc-linux-gnu) on a Debian 4 like this Linux 2.6.18-6-k7 #1 SMP Tue May 5 01:21:08 UTC 2009 i686 GNU/Linux and compiled everything with gcc/gfortran 4.3.3 Anything else I should provide? I'd be happy for any pointers! Cheers, Dennis -- Zentrum für Technomathematik, AG Optimierung und Optimale Steuerung fon: 0421-218.63866 fax: 0421-218.9863866 web: www.worhp.de |
|
From: Dan K. <da...@ke...> - 2009-06-04 14:18:26
|
On Thu, Jun 4, 2009 at 6:16 AM, Dennis Wassel <dw...@ma...> wrote: > Anyway, the matter at hand really is that valgrind trashes my console > with strange characters, some of them proper ascii ones, some of them > non-printable or control characters. 3.3.1 did not do this, but > otherwise produced pretty much the same output. What happens if you use --log-file=foo.log? Does the garbage go in the log file instead of the console? What if you valgrind /bin/true? Still garbage? What if you switch back to 3.3.1? |
|
From: Dennis W. <dw...@ma...> - 2009-06-05 08:37:41
|
Dan Kegel schrieb: > On Thu, Jun 4, 2009 at 6:16 AM, Dennis Wassel > <dw...@ma...> wrote: >> Anyway, the matter at hand really is that valgrind trashes my console >> with strange characters, some of them proper ascii ones, some of them >> non-printable or control characters. 3.3.1 did not do this, but >> otherwise produced pretty much the same output. > > What happens if you use --log-file=foo.log? Does the garbage go in the log > file instead of the console? $ valgrind --log-file=foo.log /bin/true $ cat foo.log --941206317-Æ Memcheck, a memory error detector. --941206317-Æ Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. --941206317-Æ Using LibVEX rev 1884, a library for dynamic binary translation. --941206317-Æ Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. --941206317-Æ Using valgrind-3.4.1, a dynamic binary instrumentation framework. --941206317-Æ Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. --941206317-Æ For more details, rerun with: -v --941206317-Æ Ù-3289-Æ My PID = 26317, parent PID = 3289. Prog and args are: Ù-3289-Æ /bin/true -0-Æ 1 1 ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1) 0 malloc/free: in use at exit: 0 bytes in 0 blocks. 0 malloc/free: 2 allocs, 2 frees, 36 bytes allocated. 1 For counts of detected errors, rerun with: -v 1 All heap blocks were freed -- no leaks are possible. Yep, it does. > What if you valgrind /bin/true? Still garbage? $ valgrind /bin/true --941206317-Æ Memcheck, a memory error detector. --941206317-Æ Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. --941206317-Æ Using LibVEX rev 1884, a library for dynamic binary translation. --941206317-Æ Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. --941206317-Æ Using valgrind-3.4.1, a dynamic binary instrumentation framework. --941206317-Æ Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. --941206317-Æ For more details, rerun with: -v --941206317-Æ 1 1 ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1) 0 malloc/free: in use at exit: 0 bytes in 0 blocks. 0 malloc/free: 2 allocs, 2 frees, 36 bytes allocated. 1 For counts of detected errors, rerun with: -v 1 All heap blocks were freed -- no leaks are possible. Still garbage. > What if you switch back to 3.3.1? $ valgrind /bin/true ==27327== Memcheck, a memory error detector. ==27327== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==27327== Using LibVEX rev 1854, a library for dynamic binary translation. ==27327== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==27327== Using valgrind-3.3.1, a dynamic binary instrumentation framework. ==27327== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==27327== For more details, rerun with: -v ==27327== ==27327== ==27327== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1) ==27327== malloc/free: in use at exit: 0 bytes in 0 blocks. ==27327== malloc/free: 2 allocs, 2 frees, 36 bytes allocated. ==27327== For counts of detected errors, rerun with: -v ==27327== All heap blocks were freed -- no leaks are possible. No garbage! Thanks, Dennis -- Zentrum für Technomathematik, AG Optimierung und Optimale Steuerung fon: 0421-218.63866 fax: 0421-218.9863866 web: www.worhp.de |
|
From: Dennis W. <dw...@ma...> - 2009-06-05 08:40:16
|
Julian Seward schrieb: >> --941206317-Æ Memcheck, a memory error detector > > That looks extremely strange, and it looks to me like there is some > problem in Valgrind's internal implementation of printf, or maybe in > the varargs code that gcc generates for calls to it. Are you using > some kind of hacked toolchain to build Valgrind? Did you make any > changes at all to the Valgrind sources? > > J Sorry, I completely forgot to reply-to-all. Here you go: Nope, just plain ol' gcc-4.3.3 (self-compiled, non-root install, works like a treat otherwise). The only change I had to make to valgrind is in one of the testcases, where I had to #include another header because PTHREAD_MAX_something was undefined, but valgrind itsself compiled without errors (some inliner warnings, that's all) Thanks, Dennis -- Zentrum für Technomathematik, AG Optimierung und Optimale Steuerung fon: 0421-218.63866 fax: 0421-218.9863866 web: www.worhp.de |
|
From: Dan K. <da...@ke...> - 2009-06-05 14:12:58
|
Did you build 3.3.1 the same way you built the current valgrind? What OS & CPU is this exactly? Is the valgrind output left column, --941206317-Æ always the same? Is that the real PID? On Fri, Jun 5, 2009 at 1:37 AM, Dennis Wassel<dw...@ma...> wrote: > Dan Kegel schrieb: >> On Thu, Jun 4, 2009 at 6:16 AM, Dennis Wassel >> <dw...@ma...> wrote: >>> Anyway, the matter at hand really is that valgrind trashes my console >>> with strange characters, some of them proper ascii ones, some of them >>> non-printable or control characters. 3.3.1 did not do this, but >>> otherwise produced pretty much the same output. >> >> What happens if you use --log-file=foo.log? Does the garbage go in the log >> file instead of the console? > > $ valgrind --log-file=foo.log /bin/true > $ cat foo.log > --941206317-Æ Memcheck, a memory error detector. > --941206317-Æ Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward > et al. > --941206317-Æ Using LibVEX rev 1884, a library for dynamic binary > translation. > --941206317-Æ Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. > --941206317-Æ Using valgrind-3.4.1, a dynamic binary instrumentation > framework. > --941206317-Æ Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward > et al. > --941206317-Æ For more details, rerun with: -v > --941206317-Æ > Ù-3289-Æ My PID = 26317, parent PID = 3289. Prog and args are: > Ù-3289-Æ /bin/true > -0-Æ > 1 > 1 ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1) > 0 malloc/free: in use at exit: 0 bytes in 0 blocks. > 0 malloc/free: 2 allocs, 2 frees, 36 bytes allocated. > 1 For counts of detected errors, rerun with: -v > 1 All heap blocks were freed -- no leaks are possible. > > Yep, it does. > >> What if you valgrind /bin/true? Still garbage? > > $ valgrind /bin/true > --941206317-Æ Memcheck, a memory error detector. > --941206317-Æ Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward > et al. > --941206317-Æ Using LibVEX rev 1884, a library for dynamic binary > translation. > --941206317-Æ Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. > --941206317-Æ Using valgrind-3.4.1, a dynamic binary instrumentation > framework. > --941206317-Æ Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward > et al. > --941206317-Æ For more details, rerun with: -v > --941206317-Æ > 1 > 1 ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1) > 0 malloc/free: in use at exit: 0 bytes in 0 blocks. > 0 malloc/free: 2 allocs, 2 frees, 36 bytes allocated. > 1 For counts of detected errors, rerun with: -v > 1 All heap blocks were freed -- no leaks are possible. > > Still garbage. > >> What if you switch back to 3.3.1? > > $ valgrind /bin/true > ==27327== Memcheck, a memory error detector. > ==27327== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. > ==27327== Using LibVEX rev 1854, a library for dynamic binary translation. > ==27327== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. > ==27327== Using valgrind-3.3.1, a dynamic binary instrumentation framework. > ==27327== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. > ==27327== For more details, rerun with: -v > ==27327== > ==27327== > ==27327== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1) > ==27327== malloc/free: in use at exit: 0 bytes in 0 blocks. > ==27327== malloc/free: 2 allocs, 2 frees, 36 bytes allocated. > ==27327== For counts of detected errors, rerun with: -v > ==27327== All heap blocks were freed -- no leaks are possible. > > No garbage! > > Thanks, > Dennis > > -- > Zentrum für Technomathematik, AG Optimierung und Optimale Steuerung > fon: 0421-218.63866 fax: 0421-218.9863866 web: www.worhp.de > |
|
From: Dennis W. <dw...@ma...> - 2009-06-05 14:52:37
|
Dan Kegel schrieb: > Did you build 3.3.1 the same way you built the current valgrind? Yes, I did a fresh built after experiencing problems with 3.4.1. ./configure --prefix=/localdata (non-root installation) To switch between versions, I just `make install` the one I want to use - could this cause any problems? Seeing that valgrind has no dependencies except for libc, this seems unlikely - you tell me... > What OS & CPU is this exactly? $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping : 2 cpu MHz : 2004.238 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc bogomips : 4011.66 [snipped the second core] $ cat /proc/version Linux version 2.6.18-6-k7 (Debian 2.6.18.dfsg.1-24etch2) (da...@de...) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Tue May 5 01:21:08 UTC 2009 (Note that I use a self-compiled gcc 4.3.3) > Is the valgrind output left column, > --941206317-Æ > always the same? Is that the real PID? Good catch! This is constant regardless of the program I run or how many times I repeat it, so AFAIK it cannot be the PID. Some additional notes and thoughts: This is not the first time this machine shows some signs of strange behaviour - gcc 4.4.0 bootstrap fails for as yet unknown reasons. But hey, it's Debian, shouldn't it be outdated, but otherwise fine? The system's glibc is definitely ancient, and valgrind spots many invalid reads and frees that seem related to the dynamic linker. Still nothing that should cause any headache, should it? Cheers, Dennis -- Zentrum für Technomathematik, AG Optimierung und Optimale Steuerung fon: 0421-218.63866 fax: 0421-218.9863866 web: www.worhp.de |