|
From: Fabio M. <fab...@gm...> - 2005-03-04 14:46:44
|
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. Fabio |
|
From: Nicholas N. <nj...@cs...> - 2005-03-05 01:24:04
|
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 |
|
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 > |
|
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 > > > |
|
From: Tom H. <to...@co...> - 2005-03-23 17:37:56
|
In message <171...@ma...>
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...
Did you return a defined value from main? You do know that main
should return int and not void I assume?
The C library should just be passing whatever you returned from
main to the exit_group system call as the exit code, so if it is
undefined that most likely originates in your program. It could
be a bug in libc of course, but that seems unlikely in this case.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Fabio M. <fab...@gm...> - 2005-03-23 19:15:16
|
Yes I did return an int value from main.... But I double checked it now and the error doesn't appear anymore. How odd... On Wed, 23 Mar 2005 17:37:42 GMT, Tom Hughes <to...@co...> wrote: > In message <171...@ma...> > 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... > > Did you return a defined value from main? You do know that main > should return int and not void I assume? > > The C library should just be passing whatever you returned from > main to the exit_group system call as the exit code, so if it is > undefined that most likely originates in your program. It could > be a bug in libc of course, but that seems unlikely in this case. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > > ------------------------------------------------------- > This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows > Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register > by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |