|
From: Fabio M. <fab...@gm...> - 2005-03-23 17:29:02
|
Sorry, didn't express myself quite well.... It now shows this new error besides the old ones, not in their place. Thanks On Wed, 23 Mar 2005 14:27:17 -0300, Fabio Margarido <fab...@gm...> wrote: > 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 > > > |