|
From: tic t. <hot...@ho...> - 2008-11-26 21:27:56
|
Hello, I have a question about the *.supp files located in the source tree after configure and under lib/valgrind in the runtime tree after install. Are those used for compilation at all (I looked quickly at the Makefile and it does not seem like it ..)? Are they used at runtime and in which fashion (static or dynamic library linking)? My main concern is that I am running binaries that are already using glibc and I would like to make sure that neither valgrind compilation or runtime is modifying the existing glibc libraries. Thanks for any help, Sebastien. |
|
From: Christian P. <tr...@ge...> - 2010-10-02 21:37:08
|
hey, I just can't help myself anymore in getting those f***g glibc errors off the screen. I also can't believe, that I am expected to generate a big list of suppression files just to make valgrind not complain about glibc - even when running /bin/echo. IIRC someone once told, these are because glibc is trying to optimize alot. somewhere else I read, that some of them are also because valgrind does not understand recent sse2 optimizations withing glibc. and in the end, I am lost with valgrind. I also took a look at the FAQ of valgrind, but didn't find any hint. So I am hoping to get a helpful advice on the list now. Please, if someone has an idea on how I could get rid of them, please share with me. :) Best regards, Christian. $ valgrind /bin/echo ==18645== Memcheck, a memory error detector ==18645== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==18645== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==18645== Command: /bin/echo ==18645== ==18645== Conditional jump or move depends on uninitialised value(s) ==18645== at 0x40166D6: index (strchr.S:56) ==18645== by 0x4007314: expand_dynamic_string_token (dl-load.c:324) ==18645== by 0x4007727: _dl_map_object (dl-load.c:2186) ==18645== by 0x400199A: map_doit (rtld.c:630) ==18645== by 0x400D9C5: _dl_catch_error (dl-error.c:178) ==18645== by 0x400189E: do_preload (rtld.c:814) ==18645== by 0x40044DA: dl_main (rtld.c:1693) ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) ==18645== by 0x40014D2: _dl_start (rtld.c:334) ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) ==18645== ==18645== Conditional jump or move depends on uninitialised value(s) ==18645== at 0x40166DB: index (strchr.S:59) ==18645== by 0x4007314: expand_dynamic_string_token (dl-load.c:324) ==18645== by 0x4007727: _dl_map_object (dl-load.c:2186) ==18645== by 0x400199A: map_doit (rtld.c:630) ==18645== by 0x400D9C5: _dl_catch_error (dl-error.c:178) ==18645== by 0x400189E: do_preload (rtld.c:814) ==18645== by 0x40044DA: dl_main (rtld.c:1693) ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) ==18645== by 0x40014D2: _dl_start (rtld.c:334) ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) ==18645== ==18645== Conditional jump or move depends on uninitialised value(s) ==18645== at 0x400AFBE: _dl_relocate_object (do-rel.h:65) ==18645== by 0x4003A32: dl_main (rtld.c:2249) ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) ==18645== by 0x40014D2: _dl_start (rtld.c:334) ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) ==18645== ==18645== Conditional jump or move depends on uninitialised value(s) ==18645== at 0x400AFC7: _dl_relocate_object (do-rel.h:68) ==18645== by 0x4003A32: dl_main (rtld.c:2249) ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) ==18645== by 0x40014D2: _dl_start (rtld.c:334) ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) ==18645== ==18645== Conditional jump or move depends on uninitialised value(s) ==18645== at 0x400AFBE: _dl_relocate_object (do-rel.h:65) ==18645== by 0x40038F2: dl_main (rtld.c:2312) ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) ==18645== by 0x40014D2: _dl_start (rtld.c:334) ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) ==18645== ==18645== Conditional jump or move depends on uninitialised value(s) ==18645== at 0x400AFC7: _dl_relocate_object (do-rel.h:68) ==18645== by 0x40038F2: dl_main (rtld.c:2312) ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) ==18645== by 0x40014D2: _dl_start (rtld.c:334) ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) ==18645== ==18645== ==18645== HEAP SUMMARY: ==18645== in use at exit: 0 bytes in 0 blocks ==18645== total heap usage: 2 allocs, 2 frees, 44 bytes allocated ==18645== ==18645== All heap blocks were freed -- no leaks are possible ==18645== ==18645== For counts of detected and suppressed errors, rerun with: -v ==18645== Use --track-origins=yes to see where uninitialised values come from ==18645== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 0 from 0) |
|
From: John R. <jr...@bi...> - 2010-10-02 23:12:14
|
> I also can't believe, that I am expected to generate a big list of > suppression files just to make valgrind not complain about glibc - even > when running /bin/echo. I get no complaints when running memcheck [with default suppressions, which are installed automatically] on Fedora 14 (beta) or Fedora 13 on x86_64. What are you running? > $ valgrind /bin/echo > ==18645== Memcheck, a memory error detector > ==18645== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. > ==18645== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info > ==18645== Command: /bin/echo > ==18645== > ==18645== Conditional jump or move depends on uninitialised value(s) > ==18645== at 0x40166D6: index (strchr.S:56) Which distribution of Linux are you running? There was a period of time when SuSE built its ld-linux.so.2 without the information that valgrind needs to intercept and replace the out-of-line, yet optimized, strchr/ strrchr/index/strlen/etc with memcheck's own versions that are more friendly towards error checking. To diagnose: readelf --symbols /lib*/ld-linux*.so.* | grep index If there is no line similar to this one [for x86-64]: 356: 0000003a9fc16ca0 124 FUNC LOCAL DEFAULT 11 index then you suffer from this problem. If so, then send a polite complaint to your distro, asking them to work better with valgrind by not applying "strip" when building ld-linux. -- |
|
From: Julian S. <js...@ac...> - 2010-10-03 22:42:51
|
What happens if you try valgrind svn trunk? svn co svn://svn.valgrind.org/valgrind/trunk cd trunk ./autogen.sh then configure/build/install as normal J On Saturday, October 02, 2010, Christian Parpart wrote: > hey, > > I just can't help myself anymore in getting those f***g glibc errors off > the screen. > I also can't believe, that I am expected to generate a big list of > suppression files just to make valgrind not complain about glibc - even > when running /bin/echo. > > IIRC someone once told, these are because glibc is trying to optimize > alot. somewhere else I read, that some of them are also because valgrind > does not understand recent sse2 optimizations withing glibc. and in the > end, I am lost with valgrind. > > I also took a look at the FAQ of valgrind, but didn't find any hint. So I > am hoping to get a helpful advice on the list now. Please, if someone has > an idea on how I could get rid of them, please share with me. :) > > Best regards, > Christian. > > $ valgrind /bin/echo > ==18645== Memcheck, a memory error detector > ==18645== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. > ==18645== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info > ==18645== Command: /bin/echo > ==18645== > ==18645== Conditional jump or move depends on uninitialised value(s) > ==18645== at 0x40166D6: index (strchr.S:56) > ==18645== by 0x4007314: expand_dynamic_string_token (dl-load.c:324) > ==18645== by 0x4007727: _dl_map_object (dl-load.c:2186) > ==18645== by 0x400199A: map_doit (rtld.c:630) > ==18645== by 0x400D9C5: _dl_catch_error (dl-error.c:178) > ==18645== by 0x400189E: do_preload (rtld.c:814) > ==18645== by 0x40044DA: dl_main (rtld.c:1693) > ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) > ==18645== by 0x40014D2: _dl_start (rtld.c:334) > ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) > ==18645== > ==18645== Conditional jump or move depends on uninitialised value(s) > ==18645== at 0x40166DB: index (strchr.S:59) > ==18645== by 0x4007314: expand_dynamic_string_token (dl-load.c:324) > ==18645== by 0x4007727: _dl_map_object (dl-load.c:2186) > ==18645== by 0x400199A: map_doit (rtld.c:630) > ==18645== by 0x400D9C5: _dl_catch_error (dl-error.c:178) > ==18645== by 0x400189E: do_preload (rtld.c:814) > ==18645== by 0x40044DA: dl_main (rtld.c:1693) > ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) > ==18645== by 0x40014D2: _dl_start (rtld.c:334) > ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) > ==18645== > ==18645== Conditional jump or move depends on uninitialised value(s) > ==18645== at 0x400AFBE: _dl_relocate_object (do-rel.h:65) > ==18645== by 0x4003A32: dl_main (rtld.c:2249) > ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) > ==18645== by 0x40014D2: _dl_start (rtld.c:334) > ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) > ==18645== > ==18645== Conditional jump or move depends on uninitialised value(s) > ==18645== at 0x400AFC7: _dl_relocate_object (do-rel.h:68) > ==18645== by 0x4003A32: dl_main (rtld.c:2249) > ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) > ==18645== by 0x40014D2: _dl_start (rtld.c:334) > ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) > ==18645== > ==18645== Conditional jump or move depends on uninitialised value(s) > ==18645== at 0x400AFBE: _dl_relocate_object (do-rel.h:65) > ==18645== by 0x40038F2: dl_main (rtld.c:2312) > ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) > ==18645== by 0x40014D2: _dl_start (rtld.c:334) > ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) > ==18645== > ==18645== Conditional jump or move depends on uninitialised value(s) > ==18645== at 0x400AFC7: _dl_relocate_object (do-rel.h:68) > ==18645== by 0x40038F2: dl_main (rtld.c:2312) > ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) > ==18645== by 0x40014D2: _dl_start (rtld.c:334) > ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) > ==18645== > > ==18645== > ==18645== HEAP SUMMARY: > ==18645== in use at exit: 0 bytes in 0 blocks > ==18645== total heap usage: 2 allocs, 2 frees, 44 bytes allocated > ==18645== > ==18645== All heap blocks were freed -- no leaks are possible > ==18645== > ==18645== For counts of detected and suppressed errors, rerun with: -v > ==18645== Use --track-origins=yes to see where uninitialised values come > from ==18645== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 0 from > 0) > > > > --------------------------------------------------------------------------- > --- Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Evgeniy S. <eu...@go...> - 2010-10-04 10:10:43
|
On Sun, Oct 3, 2010 at 1:18 AM, Christian Parpart <tr...@ge...> wrote: > hey, > > I just can't help myself anymore in getting those f***g glibc errors off > the screen. > I also can't believe, that I am expected to generate a big list of > suppression files just to make valgrind not complain about glibc - even > when running /bin/echo. > > IIRC someone once told, these are because glibc is trying to optimize > alot. somewhere else I read, that some of them are also because valgrind > does not understand recent sse2 optimizations withing glibc. and in the > end, I am lost with valgrind. > I get similar reports with Valgrind that was built on a machine with a slightly different glibc version. A difference in minor version number is enough. This happens because glibc version number is hardcoded into default suppressions at build time. > I also took a look at the FAQ of valgrind, but didn't find any hint. So I > am hoping to get a helpful advice on the list now. Please, if someone has > an idea on how I could get rid of them, please share with me. :) > > Best regards, > Christian. > > $ valgrind /bin/echo > ==18645== Memcheck, a memory error detector > ==18645== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. > ==18645== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info > ==18645== Command: /bin/echo > ==18645== > ==18645== Conditional jump or move depends on uninitialised value(s) > ==18645== at 0x40166D6: index (strchr.S:56) > ==18645== by 0x4007314: expand_dynamic_string_token (dl-load.c:324) > ==18645== by 0x4007727: _dl_map_object (dl-load.c:2186) > ==18645== by 0x400199A: map_doit (rtld.c:630) > ==18645== by 0x400D9C5: _dl_catch_error (dl-error.c:178) > ==18645== by 0x400189E: do_preload (rtld.c:814) > ==18645== by 0x40044DA: dl_main (rtld.c:1693) > ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) > ==18645== by 0x40014D2: _dl_start (rtld.c:334) > ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) > ==18645== > ==18645== Conditional jump or move depends on uninitialised value(s) > ==18645== at 0x40166DB: index (strchr.S:59) > ==18645== by 0x4007314: expand_dynamic_string_token (dl-load.c:324) > ==18645== by 0x4007727: _dl_map_object (dl-load.c:2186) > ==18645== by 0x400199A: map_doit (rtld.c:630) > ==18645== by 0x400D9C5: _dl_catch_error (dl-error.c:178) > ==18645== by 0x400189E: do_preload (rtld.c:814) > ==18645== by 0x40044DA: dl_main (rtld.c:1693) > ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) > ==18645== by 0x40014D2: _dl_start (rtld.c:334) > ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) > ==18645== > ==18645== Conditional jump or move depends on uninitialised value(s) > ==18645== at 0x400AFBE: _dl_relocate_object (do-rel.h:65) > ==18645== by 0x4003A32: dl_main (rtld.c:2249) > ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) > ==18645== by 0x40014D2: _dl_start (rtld.c:334) > ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) > ==18645== > ==18645== Conditional jump or move depends on uninitialised value(s) > ==18645== at 0x400AFC7: _dl_relocate_object (do-rel.h:68) > ==18645== by 0x4003A32: dl_main (rtld.c:2249) > ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) > ==18645== by 0x40014D2: _dl_start (rtld.c:334) > ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) > ==18645== > ==18645== Conditional jump or move depends on uninitialised value(s) > ==18645== at 0x400AFBE: _dl_relocate_object (do-rel.h:65) > ==18645== by 0x40038F2: dl_main (rtld.c:2312) > ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) > ==18645== by 0x40014D2: _dl_start (rtld.c:334) > ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) > ==18645== > ==18645== Conditional jump or move depends on uninitialised value(s) > ==18645== at 0x400AFC7: _dl_relocate_object (do-rel.h:68) > ==18645== by 0x40038F2: dl_main (rtld.c:2312) > ==18645== by 0x4014BC7: _dl_sysdep_start (dl-sysdep.c:244) > ==18645== by 0x40014D2: _dl_start (rtld.c:334) > ==18645== by 0x4000BA7: ??? (in /lib64/ld-2.12.1.so) > ==18645== > > ==18645== > ==18645== HEAP SUMMARY: > ==18645== in use at exit: 0 bytes in 0 blocks > ==18645== total heap usage: 2 allocs, 2 frees, 44 bytes allocated > ==18645== > ==18645== All heap blocks were freed -- no leaks are possible > ==18645== > ==18645== For counts of detected and suppressed errors, rerun with: -v > ==18645== Use --track-origins=yes to see where uninitialised values come > from > ==18645== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 0 from 0) > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Chris P. <jud...@gm...> - 2008-11-26 22:16:50
|
The *.supp files are some pre-canned suppression that can be used to suppress some known errors with certain common libraries, have a read of http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress for more info. Valgrind doesn't modify glibc so its presence in your system won't affect applications that you're not debugging. It does supply its own versions of some common library routines in order to do its magic but this is done at runtime when an app is started under valgrind's control. On Thu, Nov 27, 2008 at 10:27 AM, tic tac <hot...@ho...> wrote: > Hello, > > I have a question about the *.supp files located in the source tree after > configure and under lib/valgrind in the runtime tree after install. Are > those used for compilation at all (I looked quickly at the Makefile and it > does not seem like it ..)? Are they used at runtime and in which fashion > (static or dynamic library linking)? > > My main concern is that I am running binaries that are already using glibc > and I would like to make sure that neither valgrind compilation or runtime > is modifying the existing glibc libraries. > > Thanks for any help, > > Sebastien. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > |
|
From: Nicholas N. <nj...@cs...> - 2008-11-27 20:47:32
|
On Wed, 26 Nov 2008, tic tac wrote: > I have a question about the *.supp files located in the source tree > after configure and under lib/valgrind in the runtime tree after > install. Are those used for compilation at all (I looked quickly at > the Makefile and it does not seem like it ..)? Are they used at > runtime and in which fashion (static or dynamic library linking)? They are read at run-time by Valgrind. When Valgrind detects an error, it consults the file contents to decide if the error should be displayed. There's no relation to compilation of any kind. > My main concern is that I am running binaries that are already using glibc > and I would like to make sure that neither valgrind compilation or runtime > is modifying the existing glibc libraries. Depends what you mean by "modifying". Valgrind makes huge modification to all code that is run, including libc, but it's all done in memory. The libraries on disk aren't modified. Nick |