|
From: Fabio M. <fab...@gm...> - 2005-03-23 17:27:20
|
I've now upgraded to valgrind2.4.0-rc4 and tried to run my program which showed the glibc bugs I'd mentioned before (with 2.2.0) and now it shows another error message: ==7483== Syscall param exit_group(exit_code) contains uninitialised byte(s) ==7483== at 0x1B9BACB4: _Exit (in /lib/tls/libc-2.3.4.so) ==7483== by 0x1B944E79: __libc_start_main (in /lib/tls/libc-2.3.4.so) ==7483== by 0x8048940: ??? (start.S:119) Just thought I'd mention it... Best regards. Fabio On Fri, 4 Mar 2005 19:23:58 -0600 (CST), Nicholas Nethercote <nj...@cs...> wrote: > On Fri, 4 Mar 2005, Fabio Margarido wrote: > > > Hi folks, I've been using valgrind for the last few weeks and it's > > really helped me. I'm new to this mailing list and quicly browsed the > > archives to find possible prior answers to my question, but couldn't > > find any.. Sorry if I'm posting duplicate questions. > > My problem is: I'm running Mandrake 10.1 on a 733 Mhz with 256 MB of > > memory box, and valgrind ran smoothly without any problems. But > > yesterday I had to upgrade my glibc from version 2.3.3 to 2.3.4, and > > running valgrind produces the following error message since then: > > > > ==1174== Conditional jump or move depends on uninitialised value(s) > > ==1174== at 0x1B8F455F: strchr (strchr.S:177) > > > > and often this other message as well: > > > > ==1247== Invalid free() / delete / delete[] > > ==1247== at 0x1B904349: free (vg_replace_malloc.c:153) > > ==1247== by 0x1BA2E1AB: (within /lib/tls/libc-2.3.4.so) > > ==1247== by 0x1BA2DC51: __libc_freeres (in /lib/tls/libc-2.3.4.so) > > ==1247== by 0x1B8FDC04: _vgw(float, long double,...)(...)(long > > double,...)(short) (vg_intercept.c:117) > > ==1247== Address 0x1B8FBD58 is not stack'd, malloc'd or (recently) free'd > > > > The same program ran smoothly when I had glibc2.3.3. Has anyone else > > had that sort of problem or know the cause and how to fix it? Thanks a > > lot. > > They're probably bugs in glibc. For the second one, try > --run-libc-freeres=no, which might make it go away (but also might make > --leak-check=yes report leaks in glibc that you aren't interested in). Or > you could write a suppression for it. > > For the first, it's harder to say, but suppressing it might be the best > thing. > > N > |