I'm running valgring on one of my personal projects and it is showing: Conditional jump or move depends on unitialized value(s) 1 at 0x3c0095b0:_dl_relocate_object (in /lib/ld-2.3.3.so) This is occurring several times in the program, (and the program is pretty generic). Hoping you can pass this on to someone who knows more.
what valgrind version are you using? a minimal program triggering that error might help...
This sort of error is shown by valgrind when an conditional statement's expression doesn't have an initialized value. I was hoping you could inspect the code at _dl_relocate_object and see what conditional statements are at that routine and see if there is merit to valgrind's claim. (Usually it's pretty obvious). I don't know what in my code was triggering it. If you tell me what source tar is used to make up that lib I'll look myself. It might be just a blown stack on my part causing faulty errors (but it was consistently at that location over several runs). A visual inspection should suffice to determine if it is nonsense or not. Sorry I can't give more clues.
Hi All, This may be related, Here is a minimal program that reproduces the problem on my system (glibc-2.3.2-r9, valgrind-2.0.0, Linus kernel-2.6.6) ============================================ #include <stdio.h> #include <netdb.h> int main() { struct servent *sp = NULL; sp = getservbyname( "nfs", "udp" ); if( sp != NULL ) { printf("nfs udp port: %d\n", ntohs( sp->s_port )); } else { printf("barf.\n"); } return 0; } ============================================ Here is valgrinds output ============================================== mike@gamma glibc_bug $ valgrind ./bug ==9937== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==9937== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==9937== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==9937== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==9937== Estimated CPU clock rate is 1798 MHz ==9937== For more details, rerun with: -v ==9937== ==9937== Invalid read of size 1 ==9937== at 0x4000FB7A: (within /lib/ld-2.3.2.so) ==9937== by 0x40357AA9: (within /lib/libc-2.3.2.so) ==9937== by 0x4000B635: _dl_catch_error (in /lib/ld-2.3.2.so) ==9937== by 0x40358108: _dl_open (in /lib/libc-2.3.2.so) ==9937== Address 0xFFFFE210 is not stack'd, malloc'd or free'd ==9937== ==9937== Invalid read of size 1 ==9937== at 0x4000FB7A: (within /lib/ld-2.3.2.so) ==9937== by 0x4000A128: (within /lib/ld-2.3.2.so) ==9937== by 0x4000B635: _dl_catch_error (in /lib/ld-2.3.2.so) ==9937== by 0x4000ABA0: _dl_map_object_deps (in /lib/ld-2.3.2.so) ==9937== Address 0xFFFFE210 is not stack'd, malloc'd or free'd ==9937== ==9937== Conditional jump or move depends on uninitialised value(s) ==9937== at 0x40009064: _dl_relocate_object (in /lib/ld-2.3.2.so) ==9937== by 0x40357EAE: (within /lib/libc-2.3.2.so) ==9937== by 0x4000B635: _dl_catch_error (in /lib/ld-2.3.2.so) ==9937== by 0x40358108: _dl_open (in /lib/libc-2.3.2.so) ==9937== ==9937== Conditional jump or move depends on uninitialised value(s) ==9937== at 0x400090B5: _dl_relocate_object (in /lib/ld-2.3.2.so) ==9937== by 0x40357EAE: (within /lib/libc-2.3.2.so) ==9937== by 0x4000B635: _dl_catch_error (in /lib/ld-2.3.2.so) ==9937== by 0x40358108: _dl_open (in /lib/libc-2.3.2.so) barf. ==9937== ==9937== Invalid read of size 1 ==9937== at 0x40358446: _dl_close (in /lib/libc-2.3.2.so) ==9937== by 0x403590BA: (within /lib/libc-2.3.2.so) ==9937== by 0x4000B635: _dl_catch_error (in /lib/ld-2.3.2.so) ==9937== by 0x40358FFD: (within /lib/libc-2.3.2.so) ==9937== Address 0x1E7 is not stack'd, malloc'd or free'd Segmentation fault mike@gamma glibc_bug $ ============================================== The fact that getservbyname fails isn't the problem. It should, since nfs isn't in my /etc/services file. But the valgrind messages and the segfault are the problem. The call to getservbyname, which causes glibc to load some .so somewhere (libnss?) is what triggers the error. I'd be happy to build a debug enabled glibc so a better error message can be obtained. I tried editing make.conf and adding debug to USE="...." and -g to CFLAGS="..." but this didn't work. I'm guessing I'll have to edit glibc's ebuild to get a debug enabled build.. Is there a better way to do this? It would be nice to have two versions of glibc installed, a debug build and a production/optimized build.
Michael/Chris, can you confirm that this problem has been solved in glibc 2.3.4? P.S.: You can merge glibc using --buildpkg and copy the resulting package over to root's home for instance. If you do this once with debug and once without, you can swap between the two fairly easily. Watch out though... you wouldn't want to merge a glibc version that your system was not built against!!
glibc 2.3.4 has the same warnings when using valgrind and .so files. It happens everytime you load a .so file (the nss sample mention is very nice, gnomeprint loading cups plugin is another), or just use dlopen by hand.
Hello All, Here is an update on the bug. glibc-2.3.4.20041102-r1, valgrind-2.2.0, Linus kernel 2.6.9 The segfault and invalid reads are fixed, but there are still the Conditional jump or move depends on uninitialized values. Same test program as my previous post, here is valgrinds output. -------------------------------- gamma tmp $ valgrind --tool=memcheck ./a.out ==7796== Memcheck, a memory error detector for x86-linux. ==7796== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==7796== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==7796== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==7796== For more details, rerun with: -v ==7796== ==7796== Conditional jump or move depends on uninitialised value(s) ==7796== at 0x1B8ECC64: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E5C9C: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8F28AC: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E4B46: (within /lib/ld-2.3.4.so) ==7796== ==7796== Conditional jump or move depends on uninitialised value(s) ==7796== at 0x1B8ECC6C: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E5C9C: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8F28AC: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E4B46: (within /lib/ld-2.3.4.so) ==7796== ==7796== Conditional jump or move depends on uninitialised value(s) ==7796== at 0x1B8ECD9A: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E5C9C: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8F28AC: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E4B46: (within /lib/ld-2.3.4.so) ==7796== ==7796== Conditional jump or move depends on uninitialised value(s) ==7796== at 0x1B8ECDDD: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E5C9C: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8F28AC: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E4B46: (within /lib/ld-2.3.4.so) ==7796== ==7796== Conditional jump or move depends on uninitialised value(s) ==7796== at 0x1B8ECC64: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E5D1A: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8F28AC: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E4B46: (within /lib/ld-2.3.4.so) ==7796== ==7796== Conditional jump or move depends on uninitialised value(s) ==7796== at 0x1B8ECC6C: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E5D1A: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8F28AC: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E4B46: (within /lib/ld-2.3.4.so) ==7796== ==7796== Conditional jump or move depends on uninitialised value(s) ==7796== at 0x1B8ECDDD: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E5D1A: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8F28AC: (within /lib/ld-2.3.4.so) ==7796== by 0x1B8E4B46: (within /lib/ld-2.3.4.so) ==7796== ==7796== Conditional jump or move depends on uninitialised value(s) ==7796== at 0x1B8ECD9A: (within /lib/ld-2.3.4.so) ==7796== by 0x1BA02A16: (within /lib/tls/libc-2.3.4.so) ==7796== by 0x1B8EF585: (within /lib/ld-2.3.4.so) ==7796== by 0x1BA02DF7: _dl_open (in /lib/tls/libc-2.3.4.so) ==7796== ==7796== Conditional jump or move depends on uninitialised value(s) ==7796== at 0x1B8ECDDD: (within /lib/ld-2.3.4.so) ==7796== by 0x1BA02A16: (within /lib/tls/libc-2.3.4.so) ==7796== by 0x1B8EF585: (within /lib/ld-2.3.4.so) ==7796== by 0x1BA02DF7: _dl_open (in /lib/tls/libc-2.3.4.so) barf. ==7796== ==7796== ERROR SUMMARY: 15 errors from 9 contexts (suppressed: 0 from 0) ==7796== malloc/free: in use at exit: 0 bytes in 0 blocks. ==7796== malloc/free: 52 allocs, 52 frees, 3815 bytes allocated. ==7796== For a detailed leak analysis, rerun with: --leak-check=yes ==7796== For counts of detected errors, rerun with: -v --------------------------------
Looks like you're using a stripped ld this time. Valgrind comes with a standard set of suppressions, but they need symbols.
Maurice, Thanks for the tip, I built a non-stripped version of glibc and the warnings are now suppressed. Anyways, AFAIK this bug is fixed, but it is Chris Bruner who reported it.
To answer Chris Bruner's question in comment #2; ld is part of glibc. I'll assume for now that we will not implement a fix for this and that valgrind's default suppression file suppresses the message. Chris, if you do not agree with this, please say so.
*** Bug 264558 has been marked as a duplicate of this bug. ***
