You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(5) |
2
(12) |
3
(2) |
|
4
(1) |
5
(3) |
6
(4) |
7
(9) |
8
(7) |
9
(3) |
10
(4) |
|
11
(3) |
12
(16) |
13
(9) |
14
(16) |
15
(7) |
16
|
17
|
|
18
(1) |
19
(1) |
20
(9) |
21
(4) |
22
(1) |
23
(6) |
24
|
|
25
|
26
(2) |
27
(8) |
28
(12) |
29
(14) |
30
(8) |
31
(2) |
|
From: Jeffrey S. <fe...@xi...> - 2003-05-08 22:40:22
|
If the number of callers specified in the suppression rule is >= VG_N_SUPP_CALLERS, the parser gets confused. The attached patch fixes this condition. Jeff -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. fe...@xi... - www.ximian.com |
|
From: Troels W. H. <tr...@th...> - 2003-05-08 16:28:29
|
Thanks. Let me know if you want me to test any changes. Troels -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Julian Seward Sent: 8. mai 2003 10:04 To: Troels Walsted Hansen; val...@li... Subject: Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind I imagine this is similar to other problems I fixed ... there is two implementations of errno, in effect, and threaded one and a non-threaded one and they are getting mixed up. I'll look into it. Thx. J |
|
From: Nicholas N. <nj...@ca...> - 2003-05-08 14:38:25
|
On Thu, 8 May 2003, Andreas Oesterhelt wrote: > The other case is about inet_ntoa, which is supposed to reuse the same > statically allocated buffer in subsequent requests. Yet I get multiple > reports like this one: > > ==23379== 200 bytes in 1 blocks are still reachable in loss record 9 of 12 > ==23379== at 0x40244FF4: my_malloc (vg_libpthread.c:267) > ==23379== by 0x40246B41: get_or_allocate_specifics_ptr (vg_libpthread.c:1392) > ==23379== by 0x40246C56: __pthread_key_create (vg_libpthread.c:1429) > ==23379== by 0x40342DF1: init (in /lib/libc.so.6) > ==23379== by 0x40246E7C: __pthread_once (vg_libpthread.c:1514) > ==23379== by 0x40342D18: inet_ntoa (in /lib/libc.so.6) > ==23379== by 0x805F812: accept_connection (jbsockets.c:714) > ==23379== by 0x806204D: listen_loop (jcc.c:2252) > ==23379== by 0x8061D27: main (jcc.c:2072) > ==23379== by 0x402797ED: __libc_start_main (in /lib/libc.so.6) > ==23379== by 0x80496F0: (within /home/oes/projekte/privoxy/current/privoxy) > > How and why does __pthread_once get called from within inet_ntoa and what > does valgrind's vg_libpthread need 200 bytes for? I don't know why __pthread_once is being called, but its' a leak in Valgrind's libpthread.so; mmm, embarassing :( I committed a suppression for it in the CVS HEAD this morning (it was very hard to track down so we settled with suppressing it). N |
|
From: Crispin F. <cr...@th...> - 2003-05-08 14:37:14
|
Hi, > The other case is about inet_ntoa, which is supposed to reuse the same > statically allocated buffer in subsequent requests. Yet I get multiple > reports like this one: > > ==23379== 200 bytes in 1 blocks are still reachable in loss record 9 of 12 > ==23379== at 0x40244FF4: my_malloc (vg_libpthread.c:267) > ==23379== by 0x40246B41: get_or_allocate_specifics_ptr (vg_libpthread.c:1392) > ==23379== by 0x40246C56: __pthread_key_create (vg_libpthread.c:1429) > ==23379== by 0x40342DF1: init (in /lib/libc.so.6) > ==23379== by 0x40246E7C: __pthread_once (vg_libpthread.c:1514) > ==23379== by 0x40342D18: inet_ntoa (in /lib/libc.so.6) > ==23379== by 0x805F812: accept_connection (jbsockets.c:714) > ==23379== by 0x806204D: listen_loop (jcc.c:2252) > ==23379== by 0x8061D27: main (jcc.c:2072) > ==23379== by 0x402797ED: __libc_start_main (in /lib/libc.so.6) > ==23379== by 0x80496F0: (within /home/oes/projekte/privoxy/current/privoxy) > > How and why does __pthread_once get called from within inet_ntoa and what > does valgrind's vg_libpthread need 200 bytes for? The code inside inet_ntoa uses the pthread_once function to initialise its a pthread key, which allows it to store per-thread data. Valgrind uses the 200 bytes to store the entries for each of the allocated pthread keys for each thread. I wouldn't worry about this error at all, from my reading, the worst you are likely to get is 200 bytes per thread. Crispin |
|
From: Andreas O. <oe...@oe...> - 2003-05-08 14:01:45
|
Hello, sorry if this is a FAQ or just plain stupid, but I didn't find anything helpful in the docs, FAQ, nor ML/news archives. While checking my application for memory leaks, I noticed lots of reports about allocations made from within glibc library calls, which seem to contradict the documented behaviour of these functions. For example, gethostbyname_r is not supposed to do any allocations at all (the result structure and scratch buffer are provided by the caller). Yet at exit I get lots of these: ==23379== 416 bytes in 3 blocks are still reachable in loss record 10 of 12 ==23379== at 0x40168A63: calloc (vg_clientfuncs.c:245) ==23379== by 0x4000CAAC: _dl_check_map_versions (in /lib/ld-2.2.4.so) ==23379== by 0x4035BEAD: dl_open_worker (in /lib/libc.so.6) ==23379== by 0x4000B59F: _dl_catch_error (in /lib/ld-2.2.4.so) ==23379== by 0x4035C0AD: _dl_open (in /lib/libc.so.6) ==23379== by 0x4035CD44: do_dlopen (in /lib/libc.so.6) ==23379== by 0x4000B59F: _dl_catch_error (in /lib/ld-2.2.4.so) ==23379== by 0x4035CCDF: dlerror_run (in /lib/libc.so.6) ==23379== by 0x4035CDE9: __libc_dlopen (in /lib/libc.so.6) ==23379== by 0x40340AE3: __nss_lookup_function (in /lib/libc.so.6) ==23379== by 0x40340670: __nss_next (in /lib/libc.so.6) ==23379== by 0x40343BD3: gethostbyname_r@@GLIBC_2.1.2 (in /lib/libc.so.6) ==23379== by 0x805F96F: resolve_hostname_to_ip (jbsockets.c:800) ==23379== by 0x805F269: connect_to (jbsockets.c:296) ==23379== by 0x805ED73: forwarded_connect (gateway.c:227) ==23379== by 0x80604C9: chat (jcc.c:1171) ==23379== by 0x8061491: serve (jcc.c:1692) ==23379== by 0x4024582B: thread_wrapper (vg_libpthread.c:671) ==23379== by 0x4016E9DF: (within /usr/local/lib/valgrind/valgrind.so) Looking closer it seems as if ld was callocing memory for whatever use, leaving me with a dynamic allocation that I don't have a pointer to to free it. Even stranger: This being listed under "still reachable" implies that there is a pointer -- but where? Also note the oddness of gethostbyname_r@@GLIBC_2.1.2 although the application and valgrind were compiled and run on a glibc 2.2.4 system. The other case is about inet_ntoa, which is supposed to reuse the same statically allocated buffer in subsequent requests. Yet I get multiple reports like this one: ==23379== 200 bytes in 1 blocks are still reachable in loss record 9 of 12 ==23379== at 0x40244FF4: my_malloc (vg_libpthread.c:267) ==23379== by 0x40246B41: get_or_allocate_specifics_ptr (vg_libpthread.c:1392) ==23379== by 0x40246C56: __pthread_key_create (vg_libpthread.c:1429) ==23379== by 0x40342DF1: init (in /lib/libc.so.6) ==23379== by 0x40246E7C: __pthread_once (vg_libpthread.c:1514) ==23379== by 0x40342D18: inet_ntoa (in /lib/libc.so.6) ==23379== by 0x805F812: accept_connection (jbsockets.c:714) ==23379== by 0x806204D: listen_loop (jcc.c:2252) ==23379== by 0x8061D27: main (jcc.c:2072) ==23379== by 0x402797ED: __libc_start_main (in /lib/libc.so.6) ==23379== by 0x80496F0: (within /home/oes/projekte/privoxy/current/privoxy) How and why does __pthread_once get called from within inet_ntoa and what does valgrind's vg_libpthread need 200 bytes for? Any hints are greatly appreciated. Thanks, --Andreas |
|
From: Julian S. <js...@ac...> - 2003-05-08 08:04:42
|
I imagine this is similar to other problems I fixed ... there is two
implementations of errno, in effect, and threaded one and a non-threaded
one and they are getting mixed up. I'll look into it. Thx.
J
On Wednesday 07 May 2003 10:01 am, Troels Walsted Hansen wrote:
> Sorry, I managed to forget to attach the script.
>
> Here's the script, as well as two straces, created with the below
> commands, on a RH8+glibc 2.3.3 machine.
>
> strace python dbboguserrno.py 2> strace-normal.txt
> strace valgrind python dbboguserrno.py 2> strace-valgrind.txt
>
> Both traces show the below syscall, but the instance running in Valgrind
> seems to get EAGAIN instead...
>
> open("nosuchfile.db", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = -1 ENOENT (No
> such file or directory)
>
> Troels
>
> > -----Original Message-----
> > From: Nicholas Nethercote [mailto:nj...@he...] On
> > Behalf Of Nicholas Nethercote
> > Sent: 7. mai 2003 10:43
> > To: Troels Walsted Hansen
> > Cc: val...@li...
> > Subject: Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind
> >
> > On Wed, 7 May 2003, Troels Walsted Hansen wrote:
> > > This is the expected behavior of the program.
> > >
> > > rpmdb._rpmdb.DBNoSuchFileError: (2, 'No such file or directory')
> > >
> > > This is what happens in Valgrind. RH8 and RH9 uses
> >
> > BerkeleyDB 4.0.14,
> >
> > > rpmdb._rpmdb.DBAgainError: (11, 'Resource temporarily unavailable --
> > > nosuchfile.db: Resource temporarily unavailable')
> >
> > It's possible that Valgrind's doing something slightly
> > different with file
> > handling that means you get a different behaviour. Do you have more
> > information about what exactly is happening to prompt this
> > error? Eg. is
> > it trying to open a file with the open() system call, or
> > something like
> > that? It's very difficult to know what the problem is from your
> > description so far.
> >
> > N
|
|
From: Robert W. <rj...@du...> - 2003-05-08 05:53:14
|
> =3D=3D12597=3D=3D Attempting to close unopened file descriptor 13 > =3D=3D12597=3D=3D Attempting to close unopened file descriptor 14 > =3D=3D12597=3D=3D Attempting to close unopened file descriptor 15 > =3D=3D12597=3D=3D Attempting to close unopened file descriptor 16 > =3D=3D12597=3D=3D Attempting to close unopened file descriptor 17 > =3D=3D12597=3D=3D Attempting to close unopened file descriptor 18 > etc. >=20 >=20 > It would be nice to make this message only get printed once (also I > think that this may make the supressions stuff work for these stack > traces). I've a new version coming along any day now that has a number of improvements, including removing these messages altogether. They're an annoyance and not that useful. The new version also supports a number of bits and pieces that I missed the last time (F_DUPFD, creat, etc.) and also tries to figure out more information on sockets to make debugging easier. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Tristan V. B. <va...@to...> - 2003-05-07 18:21:08
|
David Eriksson wrote: > > (It is not advisable to start a new topic by replying to an old mail. > Many mail agents threads messages so that this mail thread shows inside > of the "BerkeleyDB gets bogus errno in Valgrind" thread.) True, true. whats done is done, might as well stick to the bogus errno thread as opposed to starting a new thread with `Re:...'. I changed here: > > #ifdef GLIBC_2_1 > > int msgsnd(int msgid, void *msgp, size_t msgsz, int msgflg) > > #else > > int msgsnd(int msgid, const void *msgp, size_t msgsz, int msgflg) > > #endif for: > > #ifndef GLIBC_2_1 > > int msgsnd(int msgid, void *msgp, size_t msgsz, int msgflg) > > #else > > int msgsnd(int msgid, const void *msgp, size_t msgsz, int msgflg) > > #endif seeing as editing the config.h induced vomiting: vg_scheduler.c: In function `do_pthread_mutex_lock': vg_scheduler.c:2406: `PTHREAD_MUTEX_TIMED_NP' undeclared (first use in this function) vg_scheduler.c:2406: (Each undeclared identifier is reported only once vg_scheduler.c:2406: for each function it appears in.) vg_scheduler.c:2407: `PTHREAD_MUTEX_ADAPTIVE_NP' undeclared (first use in this function) vg_scheduler.c: In function `do_pthread_mutex_unlock': vg_scheduler.c:2519: `PTHREAD_MUTEX_TIMED_NP' undeclared (first use in this function) vg_scheduler.c:2520: `PTHREAD_MUTEX_ADAPTIVE_NP' undeclared (first use in this function) vg_scheduler.c: In function `do_pthread_cond_wait': vg_scheduler.c:2761: `PTHREAD_MUTEX_TIMED_NP' undeclared (first use in this function) vg_scheduler.c:2762: `PTHREAD_MUTEX_ADAPTIVE_NP' undeclared (first use in this functio Now everything compiles sweetly ;-) Thanks for your support, -Tristan -- Education is imposed ignorance. -- Noam Chomsky |
|
From: David E. <da...@2g...> - 2003-05-07 17:52:30
|
(It is not advisable to start a new topic by replying to an old mail. Many mail agents threads messages so that this mail thread shows inside of the "BerkeleyDB gets bogus errno in Valgrind" thread.) On Wed, 2003-05-07 at 19:26, Tristan Van Berkom wrote: > Hi everyone! > I develop jukebox apliences under linux and am considering > valgrind as a memory debugging tool. Personaly I do not have a vast > knowlage > on cpu's and all that jazz, acronymes et al so please bear with me. > > > My questions are the following: > > Considering that gcc doesn't generate opcodes for anything other > than i386 if not specified and that valgrind takes the i486 instruction > set as a baseline: > > Would it be a fatal mistake to assume that valgrind will support > the i386 instruction set as a consiquence of supporting the i486 > instruction set ((i486 >= i386) ? backwards compatible) ? > > or would I have to recompile all my code with `-march=i486' ? > > ===================== from `info gcc' (-mcpu=option) ================ > While picking a specific CPU TYPE will schedule things > appropriately for that particular chip, the compiler will not > generate any code that does not run on the i386 without the > `-march=CPU TYPE' option being used. `i586' is equivalent to > `pentium' and `i686' is equivalent to `pentiumpro'. `k6' is the > AMD chip as opposed to the Intel ones. > ===================================================================== You don't have to compile your code for i486. Compiling for i386 is just fine as the i386 instructions is a subset of the i486 instruction set. > I'm a real dunce when it comes to automake and friends ;-) > I ran `./configure --prefix=/usr/local' followed by `make'. > (after that I tried a slew of options such as --host, --build, > --target all of which I cant seem to get right even while > searching through the config.sub). Just a note: /usr/local is the default prefix. If you want valgrind installed with this prefix you don't need a single option to valgrind. > This is the compile command issued by make that failed: > ====================================================================== > source='vg_intercept.c' object='vg_intercept.o' libtool=no \ > depfile='.deps/vg_intercept.Po' tmpdepfile='.deps/vg_intercept.TPo' \ > depmode=gcc /bin/sh ../depcomp \ > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include > -DVG_LIBDIR="\"/usr/local/lib"\" -Winline -Wall -Wshadow -O > -fomit-frame-pointer -mpreferred-stack-boundary=2 -g > -fno-omit-frame-pointer -c `test -f 'vg_intercept.c' || echo > './'`vg_intercept.c > > This is the error isued: > ================================================= > vg_intercept.c:419: conflicting types for `msgsnd' > /usr/include/sys/msg.h:74: previous declaration of `msgsnd' > > and theese are the prototypes: > ============ vg_intercept.c:419 ================= > #ifdef GLIBC_2_1 > int msgsnd(int msgid, void *msgp, size_t msgsz, int msgflg) > #else > int msgsnd(int msgid, const void *msgp, size_t msgsz, int msgflg) > #endif > > ============ /usr/include/sys/msg.h ============ > extern int msgsnd __P ((int __msqid, __const void *__msgp, size_t > __msgsz, > int __msgflg)); > > I have to admit that after 3 years of seeing this damn macro in header > files I still haven't figured out exactly what it does (`__P') but I > have > a hunch that it removes some of theese leading underscores. > > What I do find strange is that in my `msg.h' msgp is `const' and > that comes from GLIBC_2_1 !!! but if that conditional directive > was buggy; nobody else would be able to compile valgrind either > (I think). (BTW, GLIBC_2_1 is defined in the config.h) > > I am using: > gcc 2.95.3 > Linux kernel 2.4.16 > glibc 2.1.3-5 > valgrind 1.9.6 (latest) > (missing anything ?) > > Any help with my compile situation is greatly apreciated. After running ./configure, remove GLIBC_2_1 from config.h. This solution is of course a hack, but you should at least be able to compile valgrind. -- -\- David Eriksson -/- www.2GooD.nu "I personally refuse to use inferior tools because of ideology." - Linus Torvalds |
|
From: Tristan V. B. <va...@to...> - 2003-05-07 17:25:52
|
Hi everyone!
I develop jukebox apliences under linux and am considering
valgrind as a memory debugging tool. Personaly I do not have a vast
knowlage
on cpu's and all that jazz, acronymes et al so please bear with me.
My questions are the following:
Considering that gcc doesn't generate opcodes for anything other
than i386 if not specified and that valgrind takes the i486 instruction
set as a baseline:
Would it be a fatal mistake to assume that valgrind will support
the i386 instruction set as a consiquence of supporting the i486
instruction set ((i486 >= i386) ? backwards compatible) ?
or would I have to recompile all my code with `-march=i486' ?
===================== from `info gcc' (-mcpu=option) ================
While picking a specific CPU TYPE will schedule things
appropriately for that particular chip, the compiler will not
generate any code that does not run on the i386 without the
`-march=CPU TYPE' option being used. `i586' is equivalent to
`pentium' and `i686' is equivalent to `pentiumpro'. `k6' is the
AMD chip as opposed to the Intel ones.
=====================================================================
I'm a real dunce when it comes to automake and friends ;-)
I ran `./configure --prefix=/usr/local' followed by `make'.
(after that I tried a slew of options such as --host, --build,
--target all of which I cant seem to get right even while
searching through the config.sub).
This is the compile command issued by make that failed:
======================================================================
source='vg_intercept.c' object='vg_intercept.o' libtool=no \
depfile='.deps/vg_intercept.Po' tmpdepfile='.deps/vg_intercept.TPo' \
depmode=gcc /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include
-DVG_LIBDIR="\"/usr/local/lib"\" -Winline -Wall -Wshadow -O
-fomit-frame-pointer -mpreferred-stack-boundary=2 -g
-fno-omit-frame-pointer -c `test -f 'vg_intercept.c' || echo
'./'`vg_intercept.c
This is the error isued:
=================================================
vg_intercept.c:419: conflicting types for `msgsnd'
/usr/include/sys/msg.h:74: previous declaration of `msgsnd'
and theese are the prototypes:
============ vg_intercept.c:419 =================
#ifdef GLIBC_2_1
int msgsnd(int msgid, void *msgp, size_t msgsz, int msgflg)
#else
int msgsnd(int msgid, const void *msgp, size_t msgsz, int msgflg)
#endif
============ /usr/include/sys/msg.h ============
extern int msgsnd __P ((int __msqid, __const void *__msgp, size_t
__msgsz,
int __msgflg));
I have to admit that after 3 years of seeing this damn macro in header
files I still haven't figured out exactly what it does (`__P') but I
have
a hunch that it removes some of theese leading underscores.
What I do find strange is that in my `msg.h' msgp is `const' and
that comes from GLIBC_2_1 !!! but if that conditional directive
was buggy; nobody else would be able to compile valgrind either
(I think). (BTW, GLIBC_2_1 is defined in the config.h)
I am using:
gcc 2.95.3
Linux kernel 2.4.16
glibc 2.1.3-5
valgrind 1.9.6 (latest)
(missing anything ?)
Any help with my compile situation is greatly apreciated.
Regards
-Tristan
--
Education is imposed ignorance. -- Noam Chomsky
|
|
From: Crispin F. <cr...@th...> - 2003-05-07 17:18:56
|
While using the fd leak checking patch by Robert Walsh, I found a fd leak in valgrind-listener, it never closes any file descriptors. While looking at the code, I removed the nanosleep() calls so that it just sits in poll() waiting for a new connection or data on an existing connection. The patch is attached. Crispin |
|
From: Crispin F. <cr...@th...> - 2003-05-07 17:15:09
|
On Tue, 2003-04-22 at 08:43, Robert Walsh wrote: > Hi all, > > Here's a new version of the file descriptor leakage patch that solves a > memory error (sigh - this is where being able to valgrind valgrind would > be handy) in my original implementation. Feedback welcome. I have been using this quite a bit recently, and it works pretty well, however I have a comment: I have some code that calls close() on the first 512 fd's, and although the stacktrace is only printed once, the "Attempting to close unopened file descriptor 13" is printed every time, giving me the following output: ==12597== Invalid close() ==12597== at 0x402FE97D: __libc_close (in /lib/libc-2.3.1.so) ==12597== by 0x8171767: ParentBoot() (parent.cpp:1623) ==12597== by 0x81AB204: main (z4.cpp:613) ==12597== by 0x4025CA50: __libc_start_main (in /lib/libc-2.3.1.so) ==12597== Attempting to close unopened file descriptor 13 ==12597== Attempting to close unopened file descriptor 14 ==12597== Attempting to close unopened file descriptor 15 ==12597== Attempting to close unopened file descriptor 16 ==12597== Attempting to close unopened file descriptor 17 ==12597== Attempting to close unopened file descriptor 18 etc. It would be nice to make this message only get printed once (also I think that this may make the supressions stuff work for these stack traces). Crispin |
|
From: Troels W. H. <tr...@th...> - 2003-05-07 09:02:46
|
Sorry, I managed to forget to attach the script.
Here's the script, as well as two straces, created with the below
commands, on a RH8+glibc 2.3.3 machine.
strace python dbboguserrno.py 2> strace-normal.txt
strace valgrind python dbboguserrno.py 2> strace-valgrind.txt
Both traces show the below syscall, but the instance running in Valgrind
seems to get EAGAIN instead...
open("nosuchfile.db", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
Troels
> -----Original Message-----
> From: Nicholas Nethercote [mailto:nj...@he...] On
> Behalf Of Nicholas Nethercote
> Sent: 7. mai 2003 10:43
> To: Troels Walsted Hansen
> Cc: val...@li...
> Subject: Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind
>
>
> On Wed, 7 May 2003, Troels Walsted Hansen wrote:
>
> > This is the expected behavior of the program.
> >
> > rpmdb._rpmdb.DBNoSuchFileError: (2, 'No such file or directory')
> >
> > This is what happens in Valgrind. RH8 and RH9 uses
> BerkeleyDB 4.0.14,
>
> > rpmdb._rpmdb.DBAgainError: (11, 'Resource temporarily unavailable --
> > nosuchfile.db: Resource temporarily unavailable')
>
> It's possible that Valgrind's doing something slightly
> different with file
> handling that means you get a different behaviour. Do you have more
> information about what exactly is happening to prompt this
> error? Eg. is
> it trying to open a file with the open() system call, or
> something like
> that? It's very difficult to know what the problem is from your
> description so far.
>
> N
>
|
|
From: Nicholas N. <nj...@ca...> - 2003-05-07 08:42:35
|
On Wed, 7 May 2003, Troels Walsted Hansen wrote: > This is the expected behavior of the program. > > rpmdb._rpmdb.DBNoSuchFileError: (2, 'No such file or directory') > > This is what happens in Valgrind. RH8 and RH9 uses BerkeleyDB 4.0.14, > rpmdb._rpmdb.DBAgainError: (11, 'Resource temporarily unavailable -- > nosuchfile.db: Resource temporarily unavailable') It's possible that Valgrind's doing something slightly different with file handling that means you get a different behaviour. Do you have more information about what exactly is happening to prompt this error? Eg. is it trying to open a file with the open() system call, or something like that? It's very difficult to know what the problem is from your description so far. N |
|
From: Troels W. H. <tr...@th...> - 2003-05-07 08:22:05
|
Valgrind 1.9.6 runs much better on RH8+glibc 2.3.2/RH9, but it doesn't
appear to be perfect yet. I have reproduced this problem on both of the
mentioned platforms.
This is the expected behavior of the program.
$ python dbboguserrno.py
Traceback (most recent call last):
File "dbboguserrno.py", line 4, in ?
filetype = db.DB_BTREE)
File "/usr/lib/python2.2/site-packages/rpmdb/dbshelve.py", line 69, in
open
d.open(filename, dbname, filetype, flags, mode)
rpmdb._rpmdb.DBNoSuchFileError: (2, 'No such file or directory')
This is what happens in Valgrind. RH8 and RH9 uses BerkeleyDB 4.0.14,
with a custom compiled Python interpreter and BerkeleyDB 3.3.11 I get
"bsddb3._db.DBError: (9, 'Bad file descriptor -- nosuchfile.db: Bad file
descriptor')" errors instead.
$ valgrind -v python dbboguserrno.py
==7099== Memcheck, a.k.a. Valgrind, a memory error detector for
x86-linux.
==7099== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==7099== Using valgrind-1.9.6, a program instrumentation system for
x86-linux.
==7099== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==7099== Startup, with flags:
==7099== --suppressions=/usr/local/lib/valgrind/default.supp
==7099== -v
==7099== Reading suppressions file: /usr/local/lib/valgrind/default.supp
==7099== Estimated CPU clock rate is 702 MHz
==7099==
==7099== Reading syms from /usr/bin/python
==7099== object doesn't have any debug info
==7099== Reading syms from /lib/ld-2.3.2.so
==7099== object doesn't have any debug info
==7099== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so
==7099== Reading syms from /usr/local/lib/valgrind/valgrind.so
==7099== Reading syms from /lib/libdl-2.3.2.so
==7099== object doesn't have any debug info
==7099== Reading syms from /usr/local/lib/valgrind/libpthread.so
==7099== Reading syms from /lib/libutil-2.3.2.so
==7099== object doesn't have any debug info
==7099== Reading syms from /lib/libm-2.3.2.so
==7099== object doesn't have a symbol table
==7099== object doesn't have any debug info
==7099== Reading syms from /lib/libc-2.3.2.so
==7099== object doesn't have a symbol table
==7099== object doesn't have any debug info
==7099== Reading syms from
/usr/lib/python2.2/lib-dynload/structmodule.so
==7099== Conditional jump or move depends on uninitialised value(s)
==7099== at 0x40008D55: elf_dynamic_do_rel.7 (in /lib/ld-2.3.2.so)
==7099== by 0x4000942A: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099== by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099== by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099==
==7099== Conditional jump or move depends on uninitialised value(s)
==7099== at 0x40008D59: elf_dynamic_do_rel.7 (in /lib/ld-2.3.2.so)
==7099== by 0x4000942A: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099== by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099== by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099==
==7099== Conditional jump or move depends on uninitialised value(s)
==7099== at 0x40009517: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099== by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099== by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099== by 0x403774AE: _dl_open (in /lib/libc-2.3.2.so)
==7099==
==7099== Conditional jump or move depends on uninitialised value(s)
==7099== at 0x40009565: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099== by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099== by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099== by 0x403774AE: _dl_open (in /lib/libc-2.3.2.so)
==7099== Reading syms from
/usr/lib/python2.2/lib-dynload/_codecsmodule.so
==7099== Reading syms from
/usr/lib/python2.2/site-packages/rpmdb/_rpmdb.so
==7099== Reading syms from /usr/lib/librpm-4.1.so
==7099== Reading syms from /usr/lib/librpmdb-4.1.so
==7099== Reading syms from /usr/lib/librpmio-4.1.so
==7099== Reading syms from /usr/lib/libpopt.so.0.0.0
==7099== Reading syms from /lib/librt-2.3.2.so
==7099== object doesn't have any debug info
==7099== Reading syms from /usr/lib/libelf.so.0.8.2
==7099== Reading syms from /usr/lib/libbz2.so.1.0.2
==7099== Reading syms from /usr/lib/python2.2/lib-dynload/cPickle.so
==7099== Reading syms from /usr/lib/python2.2/lib-dynload/cStringIO.so
Traceback (most recent call last):
File "dbboguserrno.py", line 4, in ?
filetype = db.DB_BTREE)
File "/usr/lib/python2.2/site-packages/rpmdb/dbshelve.py", line 69, in
open
d.open(filename, dbname, filetype, flags, mode)
rpmdb._rpmdb.DBAgainError: (11, 'Resource temporarily unavailable --
nosuchfile.db: Resource temporarily unavailable')
==7099==
==7099== ERROR SUMMARY: 48 errors from 4 contexts (suppressed: 2 from 1)
==7099==
==7099== 12 errors in context 1 of 4:
==7099== Conditional jump or move depends on uninitialised value(s)
==7099== at 0x40009565: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099== by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099== by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099== by 0x403774AE: _dl_open (in /lib/libc-2.3.2.so)
==7099==
==7099== 12 errors in context 2 of 4:
==7099== Conditional jump or move depends on uninitialised value(s)
==7099== at 0x40009517: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099== by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099== by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099== by 0x403774AE: _dl_open (in /lib/libc-2.3.2.so)
==7099==
==7099== 12 errors in context 3 of 4:
==7099== Conditional jump or move depends on uninitialised value(s)
==7099== at 0x40008D59: elf_dynamic_do_rel.7 (in /lib/ld-2.3.2.so)
==7099== by 0x4000942A: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099== by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099== by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099==
==7099== 12 errors in context 4 of 4:
==7099== Conditional jump or move depends on uninitialised value(s)
==7099== at 0x40008D55: elf_dynamic_do_rel.7 (in /lib/ld-2.3.2.so)
==7099== by 0x4000942A: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099== by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099== by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
--7099--
--7099-- supp: 2 __pthread_mutex_unlock/_IO_funlockfile
==7099==
==7099== IN SUMMARY: 48 errors from 4 contexts (suppressed: 2 from 1)
==7099==
==7099== malloc/free: in use at exit: 120602 bytes in 1147 blocks.
==7099== malloc/free: 31726 allocs, 30579 frees, 2322038 bytes
allocated.
==7099==
--7099-- TT/TC: 0 tc sectors discarded.
--7099-- 11223 chainings, 0 unchainings.
--7099-- translate: new 14012 (209064 -> 2646829; ratio 126:10)
--7099-- discard 0 (0 -> 0; ratio 0:10).
--7099-- dispatch: 6900000 jumps (bb entries), of which 1304733 (18%)
were unchained.
--7099-- 140/88816 major/minor sched events. 17845 tt_fast
misses.
--7099-- reg-alloc: 1950 t-req-spill, 497014+11920 orig+spill uis, 70141
total-reg-r.
--7099-- sanity: 141 cheap, 6 expensive checks.
--7099-- ccalls: 51904 C calls, 58% saves+restores avoided (178738
bytes)
--7099-- 71568 args, avg 0.87 setup instrs each (17770 bytes)
--7099-- 0% clear the stack (155712 bytes)
--7099-- 19332 retvals, 34% of reg-reg movs avoided (12842
bytes)
--
Troels Walsted Hansen
|
|
From: Nicholas N. <nj...@ca...> - 2003-05-07 07:43:40
|
On Mon, 5 May 2003, Julian Seward wrote: > > Below is the error summary at exit of my program. I understand the > > 195000 bytes in 3 block possibly lost, and it isn't a bug. The part > > that I don't understand, and can't seem to find an explanation for in > > the documents, is the section running from the line of "TT/TC:" down to > > "reg-alloc:". > > Ignore them; they are statistics about valgrind's internal workings and > have nothing much to do with your program. And don't use -v if you don't want to see them. N |
|
From: Andreas O. <oe...@oe...> - 2003-05-06 20:14:12
|
Hi Arnaud,
On Tue, 6 May 2003, Arnaud Desitter wrote:
> ;; Currently this regexp only matches the first error.
> ;; Thanks to Hans Petter Jansson <hp...@xi...> for his regexp wisdom.
> (setq compilation-error-regexp-alist
> (append compilation-error-regexp-alist
> '(("^==[0-9]+==[^(]+\(\\([^:]+\\):\\([0-9]+\\)"
> 1 2))))
thanks a lot! This works nicely when called from the
compilation-mode-hook, and despite the comment it works
for all lines matching the RE, not just the first one.
Regards,
--Andreas
|
|
From: Arnaud D. <arn...@ge...> - 2003-05-06 17:35:48
|
----- Original Message -----
From: "Andreas Oesterhelt" <oe...@oe...>
To: <val...@li...>
Sent: Tuesday, May 06, 2003 6:50 PM
Subject: [Valgrind-users] Thanks, compilation problem, Emacs mode?
> Third, does anyone know of a (X)emacs mode that would parse valgrind
> output and jump to the right locations in the source files on click, just
> like the compilation mode does? If not, does anyone feel like writing one?
> ,-)
Try that in your .emacs:
;; from Ole Aamot (ol...@gn...)
;; Valgrind (memory debugger for x86 GNU/Linux):
;; ==1332== at 0x8008621: main (vtest.c:180)
;; Currently this regexp only matches the first error.
;; Thanks to Hans Petter Jansson <hp...@xi...> for his regexp wisdom.
(setq compilation-error-regexp-alist
(append compilation-error-regexp-alist
'(("^==[0-9]+==[^(]+\(\\([^:]+\\):\\([0-9]+\\)"
1 2))))
Regards,
|
|
From: Andreas O. <oe...@oe...> - 2003-05-06 16:56:51
|
Hi, ..first of all: Thanks a lot for providing this extremely useful tool! The per-allocation stack traces saved me a lot of work debugging! Second, when compiling valgrind 1.9.6 I noticed a small problem which might either be due to a weirdness in my local setup (quite possible!) or valgrind's build process: On my glibc 2.2 system which had been correctly recognized by the configure script (#define GLIBC_2_2 1 set in config.h), compilation of coregrind/vg_intercept.c failed with some type checking errors involving struct timeval. Moving the #include <sys/time.h> statement out of its #ifdef GLIBC_2_1 resolved the issue. Third, does anyone know of a (X)emacs mode that would parse valgrind output and jump to the right locations in the source files on click, just like the compilation mode does? If not, does anyone feel like writing one? ,-) Cheers from a happy user! Regards, --Andreas |
|
From: Crispin F. <cr...@th...> - 2003-05-06 13:34:42
|
While performing some tests with valgrind, I have found a slight difference between the documentation and the behaviour with regards to tracing child processes. When a child process is fork'd and then exec'd the tracing behaviour correctly follows the --trace-children flag. However if the child process is created just by forking the main program, then it is always traced. Is this the desired behaviour? I expected it to behave like strace and ltrace and the like where they stop tracing after the fork, not after the exec. (attached is a small test program that demonstrates the tracing of children created just be a fork) Cheers Crispin |
|
From: Julian S. <js...@ac...> - 2003-05-05 23:04:10
|
Version 1.9.6 (7 May 2003 or thereabouts) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Major changes in 1.9.6: - Improved threading support for glibc >= 2.3.2 (SuSE 8.2, RedHat 9, to name but two ...) It turned out that 1.9.5 had problems with threading support on glibc >= 2.3.2, usually manifested by threaded programs deadlocking in system calls, or running unbelievably slowly. Hopefully these are fixed now. 1.9.6 is the first valgrind which gives reasonable support for glibc-2.3.2. Also fixed a 2.3.2 problem with pthread_atfork(). - Majorly expanded FAQ.txt. We've added workarounds for all common problems for which a workaround is known. Minor changes in 1.9.6: - Fix identification of the main thread's stack. Incorrect identification of it was causing some on-stack addresses to not get identified as such. This only affected the usefulness of some error messages; the correctness of the checks made is unchanged. - Support for kernels >= 2.5.68. - Dummy implementations of __libc_current_sigrtmin, __libc_current_sigrtmax and __libc_allocate_rtsig, hopefully good enough to keep alive programs which previously died for lack of them. - Fix bug in the VALGRIND_DISCARD_TRANSLATIONS client request. - Fix bug in the DWARF2 debug line info loader, when instructions following each other have source lines far from each other (e.g. with inlined functions). - Debug info reading: read symbols from both "symtab" and "dynsym" sections, rather than merely from the one that comes last in the file. - New syscall support: prctl(), creat(), lookup_dcookie(). - When checking calls to accept(), recvfrom(), getsocketopt(), don't complain if buffer values are NULL. - Try and avoid assertion failures in mash_LD_PRELOAD_and_LD_LIBRARY_PATH. - Minor bug fixes in cg_annotate. |
|
From: Julian S. <js...@ac...> - 2003-05-05 19:05:55
|
> Below is the error summary at exit of my program. I understand the > 195000 bytes in 3 block possibly lost, and it isn't a bug. The part > that I don't understand, and can't seem to find an explanation for in > the documents, is the section running from the line of "TT/TC:" down to > "reg-alloc:". Ignore them; they are statistics about valgrind's internal workings and have nothing much to do with your program. J |
|
From: Eric M. M. <emo...@be...> - 2003-05-05 18:37:24
|
All, I just started using valgrind to debug my program. To date, the program has not crashed and so I have not seen if valgrind will flag any errors, but I am trying to understand the output for the normal case. I run valgrind from within a shell script that I'll be asking my users to execute. The shell script is as follows: #!/bin/sh LD_LIBRARY_PATH=/home/emonsler/usr/local/lib:/usr/lib:/usr/openwin/lib:/usr/local/lib /home/emonsler/testing/bin/valgrind --num-callers=8 --logfile=/tmp/LindaCrash --workaround-gcc296-bugs=yes --leak-check=yes --run-libc-freeres=no -v /home/emonsler/usr/local/bin/avdisplay2.55 $* Below is the error summary at exit of my program. I understand the 195000 bytes in 3 block possibly lost, and it isn't a bug. The part that I don't understand, and can't seem to find an explanation for in the documents, is the section running from the line of "TT/TC:" down to "reg-alloc:". Where are those documented? Are the values shown errors or warnings? Thanks in advance, valgrind looks very promising and I wish that I had known about it when first debugging this program. Please cc:me on responses, as I am not subscribed to the list. TIA, Eric Monsler ==9748== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 28 from 1) --9748-- --9748-- supp: 28 write(buf)/libc-2.2.4.so/libX11.so.6.2/libX11.so.6.2(Param) ==9748== malloc/free: in use at exit: 476605 bytes in 3358 blocks. ==9748== malloc/free: 13320394 allocs, 13317036 frees, 2516779165 bytes allocate d. ==9748== ==9748== searching for pointers to 3358 not-freed blocks. ==9748== checked 8135900 bytes. ==9748== ==9748== 195000 bytes in 3 blocks are possibly lost in loss record 72 of 72 ==9748== at 0x40169340: malloc (vg_clientfuncs.c:103) ==9748== by 0x40485AF6: g_malloc (gmem.c:177) ==9748== by 0x80636EE: vReadIncomingUDP (avd_disp_msgs.c:1439) ==9748== by 0x403B6A1B: gdk_io_invoke (gdkevents.c:882) ==9748== by 0x4048274B: g_io_unix_dispatch (giounix.c:137) ==9748== by 0x4048453B: g_main_dispatch (gmain.c:656) ==9748== by 0x40484D6D: g_main_iterate (gmain.c:877) ==9748== by 0x40484F5B: g_main_run (gmain.c:935) ==9748== ==9748== LEAK SUMMARY: ==9748== definitely lost: 0 bytes in 0 blocks. ==9748== possibly lost: 195000 bytes in 3 blocks. ==9748== still reachable: 281605 bytes in 3355 blocks. ==9748== suppressed: 0 bytes in 0 blocks. ==9748== Reachable blocks (those to which a pointer was found) are not shown. ==9748== To see them, rerun with: --show-reachable=yes ==9748== --9748-- TT/TC: 0 tc sectors discarded. --9748-- 24798 chainings, 0 unchainings. --9748-- translate: new 32046 (514035 -> 7150204; ratio 139:10) --9748-- discard 0 (0 -> 0; ratio 0:10). --9748-- dispatch: 8293450000 jumps (bb entries), of which 1422416883 (17%) wer e unchained. --9748-- 165870/31416415 major/minor sched events. 2408860 tt_fast m isses. --9748-- reg-alloc: 4906 t-req-spill, 1313936+30807 orig+spill uis, 158696 total -reg-r. --9748-- sanity: 165871 cheap, 6635 expensive checks. --9748-- ccalls: 161306 C calls, 57% saves+restores avoided (544328 bytes) --9748-- 205701 args, avg 0.88 setup instrs each (45330 bytes) --9748-- 0% clear the stack (483918 bytes) --9748-- 63626 retvals, 35% of reg-reg movs avoided (43554 bytes) ( |
|
From: Nehal <ne...@ca...> - 2003-05-04 19:14:47
|
Hello, im having problems running my program with valgrind. when i type: valgrind ./myprogram it seems to work for a while then i get this last error and it freezes... and i have to kill the xterm: ==947== ==947== Conditional jump or move depends on uninitialised value(s) ==947== at 0x40160658: memchr (vg_clientfuncs.c:490) ==947== by 0x403D1F3D: _IO_getline_info_internal (in /lib/libc-2.3.1.so) ==947== by 0x403D1EC2: _IO_getline_internal (in /lib/libc-2.3.1.so) ==947== by 0x403D0ECA: _IO_fgets (in /lib/libc-2.3.1.so) ==947== ==947== Use of uninitialised value of size 4 ==947== at 0x405137D6: (within /usr/X11R6/lib/libX11.so.6.2) ==947== by 0x40513AC9: (within /usr/X11R6/lib/libX11.so.6.2) ==947== by 0x40513F6A: _XlcResolveLocaleName (in /usr/X11R6/lib/libX11.so.6.2) ==947== by 0x40517BCF: (within /usr/X11R6/lib/libX11.so.6.2) i know its not doing anything because cpu usage is at 0% btw, i got latest valgrind (1.9.5) Nehal |
|
From: Raymond R. <ra...@co...> - 2003-05-03 14:37:58
|
Hello, I have just recently started using valgrind and, I must add, am impressed - the sheer audacity of the approach is great. (Thanks to Messrs. Seward and Nethercote, and all the developers.) I would like to use it on a program I have that does asynchronous I/O without using select(). It registers a signal handler using sigaction and, on receipt of SIGIO, extracts the file descriptor that caused the signal from its second siginfo_t * argument. Since valgrind passes a NULL pointer to applications when invoking signal handlers, my program simply segfaults in its handler. My question is this: are there any plans to change the signal handling to support the propagation of the siginfo_t * supplied by the kernel to the application? I am guessing that to do so would be a fair bit of work. Am I wrong is thinking that valgrind only maintains a pending flag for each signal, rather than a true queue of signals like the kernel does? If this is in the works, I'd be interested to help if I can. If not, I'd be happy to start it. Either way, who should I talk to about this? Regards, Raymond. |