|
From: Bob D. <bd...@sr...> - 2005-07-22 19:25:31
|
Hello all, I've spent the last couple of hours trying to find the answer to this question in the archives, but I haven't found anything related to this for Fedora Core 3 and version 2.4 of valgrind. I'm a valgrind newbie, though, and I may not be looking for the right thing. Whenever I try to run valgrind, it dumps core (even on a "hello world" C ++ program) very soon after it is started... I built it from source with the -g cflag and tried to attach to it with gdb, using the --wait-for- gdb=yes feature, but I'm too ignorant to get that to do anything for me. I'm on a FC3 box. cat /proc/version tells me: Linux version 2.6.11-1.27_FC3smp (bhc...@po...) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 SMP Tue May 17 20:43:11 EDT 2005 Here's what I'm seeing when valgrind dies on me... [prompt]$ /usr/local/bin/valgrind --tool=memcheck --leak-check=yes -- show-reachable=yes -v -v -v -v --run-libc-freeres=no ../project/mybinary ==14005== Memcheck, a memory error detector for x86-linux. ==14005== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==14005== Using valgrind-2.4.0, a program supervision framework for x86- linux. ==14005== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==14005== Valgrind library directory: /usr/local/lib/valgrind ==14005== Command line ==14005== ../feemaxprj/feemax ==14005== Startup, with flags: ==14005== --tool=memcheck ==14005== --leak-check=yes ==14005== --show-reachable=yes ==14005== -v ==14005== -v ==14005== -v ==14005== -v ==14005== --run-libc-freeres=no ==14005== Contents of /proc/version: ==14005== Linux version 2.6.11-1.27_FC3smp (bhc...@po...) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 SMP Tue May 17 20:43:11 EDT 2005 ==14005== Reading syms from /home/bdusek/prj/feemax/feemaxprj/feemax (0x8048000) ==14005== Reading syms from /lib/ld-2.3.5.so (0x1B8E4000) ==14005== object doesn't have any debug info ==14005== Reading syms from /usr/local/lib/valgrind/stage2 (0xB0000000) ==14005== Reading syms from /lib/ld-2.3.5.so (0xB1000000) ==14005== object doesn't have any debug info ==14005== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so (0xB7C4E000) ==14005== Reading syms from /lib/tls/libc-2.3.5.so (0xB7EAE000) ==14005== object doesn't have any debug info ==14005== Reading syms from /lib/libdl-2.3.5.so (0xB7FD9000) ==14005== object doesn't have any debug info ==14005== Reading suppressions file: /usr/local/lib/valgrind/default.supp --14005-- Translation Cache: using 8 sectors of 7260151 bytes each --14005-- Translation Table: 300007 total entries, max occupancy 240005 (80%) ==14005== --14005-- 0k bbs: tt 0, tc 0, after allocation of sector 0 (size 7260151) --14005-- 0k bbs: tt 0, tc 0, after commission of sector 0 at time 0 ==14005== Signal 11 (SIGSEGV) appears to have lost its siginfo; I can't go on. ==14005== This may be because one of your programs has consumed your ==14005== ration of siginfo structures. ==14005== ==14005== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==14005== at 0x1B8F001A: _dl_catch_error (in /lib/ld-2.3.5.so) ==14005== by 0x1B8E740C: dl_main (in /lib/ld-2.3.5.so) ==14005== by 0x1B8F37C4: _dl_sysdep_start (in /lib/ld-2.3.5.so) ==14005== by 0x1B8E53EF: _dl_start (in /lib/ld-2.3.5.so) ==14005== by 0x1B8E47C6: (within /lib/ld-2.3.5.so) Can anyone point me in the right direction? |
|
From: Bob D. <bd...@sr...> - 2005-07-22 21:17:17
|
Also thought that it might be good to mention that the core files it's dumping aren't doing me any good either. Here's what I get when trying to run gdb on one of the core files... warning: core file may not match specified executable file. Core was generated by `'. Program terminated with signal 11, Segmentation fault. #0 0x1b8f001a in ?? () (gdb) bt #0 0x1b8f001a in ?? () Cannot access memory at address 0x52bfdfc8 On Fri, 2005-07-22 at 15:25 -0400, Bob Dusek wrote: > Hello all, > > I've spent the last couple of hours trying to find the answer to this > question in the archives, but I haven't found anything related to this > for Fedora Core 3 and version 2.4 of valgrind. I'm a valgrind newbie, > though, and I may not be looking for the right thing. > > Whenever I try to run valgrind, it dumps core (even on a "hello world" C > ++ program) very soon after it is started... I built it from source with > the -g cflag and tried to attach to it with gdb, using the --wait-for- > gdb=yes feature, but I'm too ignorant to get that to do anything for me. > > I'm on a FC3 box. > > cat /proc/version tells me: > > Linux version 2.6.11-1.27_FC3smp (bhc...@po...) (gcc > version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 SMP Tue May 17 20:43:11 > EDT 2005 > > Here's what I'm seeing when valgrind dies on me... > > [prompt]$ /usr/local/bin/valgrind --tool=memcheck --leak-check=yes -- > show-reachable=yes -v -v -v -v --run-libc-freeres=no ../project/mybinary > ==14005== Memcheck, a memory error detector for x86-linux. > ==14005== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et > al. > ==14005== Using valgrind-2.4.0, a program supervision framework for x86- > linux. > ==14005== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et > al. > ==14005== Valgrind library directory: /usr/local/lib/valgrind > ==14005== Command line > ==14005== ../feemaxprj/feemax > ==14005== Startup, with flags: > ==14005== --tool=memcheck > ==14005== --leak-check=yes > ==14005== --show-reachable=yes > ==14005== -v > ==14005== -v > ==14005== -v > ==14005== -v > ==14005== --run-libc-freeres=no > ==14005== Contents of /proc/version: > ==14005== Linux version 2.6.11-1.27_FC3smp > (bhc...@po...) (gcc version 3.4.3 20050227 (Red Hat > 3.4.3-22)) #1 SMP Tue May 17 20:43:11 EDT 2005 > ==14005== Reading syms from /home/bdusek/prj/feemax/feemaxprj/feemax > (0x8048000) > ==14005== Reading syms from /lib/ld-2.3.5.so (0x1B8E4000) > ==14005== object doesn't have any debug info > ==14005== Reading syms from /usr/local/lib/valgrind/stage2 (0xB0000000) > ==14005== Reading syms from /lib/ld-2.3.5.so (0xB1000000) > ==14005== object doesn't have any debug info > ==14005== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so > (0xB7C4E000) > ==14005== Reading syms from /lib/tls/libc-2.3.5.so (0xB7EAE000) > ==14005== object doesn't have any debug info > ==14005== Reading syms from /lib/libdl-2.3.5.so (0xB7FD9000) > ==14005== object doesn't have any debug info > ==14005== Reading suppressions > file: /usr/local/lib/valgrind/default.supp > --14005-- Translation Cache: using 8 sectors of 7260151 bytes each > --14005-- Translation Table: 300007 total entries, max occupancy 240005 > (80%) > ==14005== > --14005-- 0k bbs: tt 0, tc 0, after allocation of sector 0 (size > 7260151) > --14005-- 0k bbs: tt 0, tc 0, after commission of sector 0 at time 0 > ==14005== Signal 11 (SIGSEGV) appears to have lost its siginfo; I can't > go on. > ==14005== This may be because one of your programs has consumed your > ==14005== ration of siginfo structures. > ==14005== > ==14005== Process terminating with default action of signal 11 > (SIGSEGV): dumping core > ==14005== at 0x1B8F001A: _dl_catch_error (in /lib/ld-2.3.5.so) > ==14005== by 0x1B8E740C: dl_main (in /lib/ld-2.3.5.so) > ==14005== by 0x1B8F37C4: _dl_sysdep_start (in /lib/ld-2.3.5.so) > ==14005== by 0x1B8E53EF: _dl_start (in /lib/ld-2.3.5.so) > ==14005== by 0x1B8E47C6: (within /lib/ld-2.3.5.so) > > Can anyone point me in the right direction? > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Brian C. <cr...@fi...> - 2005-07-22 21:34:33
|
Perhaps you're trying to debug a valgrind core using your application as the executable instead of a debug build of valgrind? -- Brian Bob Dusek wrote: >Also thought that it might be good to mention that the core files it's >dumping aren't doing me any good either. Here's what I get when trying >to run gdb on one of the core files... > >warning: core file may not match specified executable file. >Core was generated by `'. >Program terminated with signal 11, Segmentation fault. >#0 0x1b8f001a in ?? () >(gdb) bt >#0 0x1b8f001a in ?? () >Cannot access memory at address 0x52bfdfc8 > > >On Fri, 2005-07-22 at 15:25 -0400, Bob Dusek wrote: > > >>Hello all, >> >>I've spent the last couple of hours trying to find the answer to this >>question in the archives, but I haven't found anything related to this >>for Fedora Core 3 and version 2.4 of valgrind. I'm a valgrind newbie, >>though, and I may not be looking for the right thing. >> >>Whenever I try to run valgrind, it dumps core (even on a "hello world" C >>++ program) very soon after it is started... I built it from source with >>the -g cflag and tried to attach to it with gdb, using the --wait-for- >>gdb=yes feature, but I'm too ignorant to get that to do anything for me. >> >>I'm on a FC3 box. >> >>cat /proc/version tells me: >> >>Linux version 2.6.11-1.27_FC3smp (bhc...@po...) (gcc >>version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 SMP Tue May 17 20:43:11 >>EDT 2005 >> >>Here's what I'm seeing when valgrind dies on me... >> >>[prompt]$ /usr/local/bin/valgrind --tool=memcheck --leak-check=yes -- >>show-reachable=yes -v -v -v -v --run-libc-freeres=no ../project/mybinary >>==14005== Memcheck, a memory error detector for x86-linux. >>==14005== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et >>al. >>==14005== Using valgrind-2.4.0, a program supervision framework for x86- >>linux. >>==14005== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et >>al. >>==14005== Valgrind library directory: /usr/local/lib/valgrind >>==14005== Command line >>==14005== ../feemaxprj/feemax >>==14005== Startup, with flags: >>==14005== --tool=memcheck >>==14005== --leak-check=yes >>==14005== --show-reachable=yes >>==14005== -v >>==14005== -v >>==14005== -v >>==14005== -v >>==14005== --run-libc-freeres=no >>==14005== Contents of /proc/version: >>==14005== Linux version 2.6.11-1.27_FC3smp >>(bhc...@po...) (gcc version 3.4.3 20050227 (Red Hat >>3.4.3-22)) #1 SMP Tue May 17 20:43:11 EDT 2005 >>==14005== Reading syms from /home/bdusek/prj/feemax/feemaxprj/feemax >>(0x8048000) >>==14005== Reading syms from /lib/ld-2.3.5.so (0x1B8E4000) >>==14005== object doesn't have any debug info >>==14005== Reading syms from /usr/local/lib/valgrind/stage2 (0xB0000000) >>==14005== Reading syms from /lib/ld-2.3.5.so (0xB1000000) >>==14005== object doesn't have any debug info >>==14005== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so >>(0xB7C4E000) >>==14005== Reading syms from /lib/tls/libc-2.3.5.so (0xB7EAE000) >>==14005== object doesn't have any debug info >>==14005== Reading syms from /lib/libdl-2.3.5.so (0xB7FD9000) >>==14005== object doesn't have any debug info >>==14005== Reading suppressions >>file: /usr/local/lib/valgrind/default.supp >>--14005-- Translation Cache: using 8 sectors of 7260151 bytes each >>--14005-- Translation Table: 300007 total entries, max occupancy 240005 >>(80%) >>==14005== >>--14005-- 0k bbs: tt 0, tc 0, after allocation of sector 0 (size >>7260151) >>--14005-- 0k bbs: tt 0, tc 0, after commission of sector 0 at time 0 >>==14005== Signal 11 (SIGSEGV) appears to have lost its siginfo; I can't >>go on. >>==14005== This may be because one of your programs has consumed your >>==14005== ration of siginfo structures. >>==14005== >>==14005== Process terminating with default action of signal 11 >>(SIGSEGV): dumping core >>==14005== at 0x1B8F001A: _dl_catch_error (in /lib/ld-2.3.5.so) >>==14005== by 0x1B8E740C: dl_main (in /lib/ld-2.3.5.so) >>==14005== by 0x1B8F37C4: _dl_sysdep_start (in /lib/ld-2.3.5.so) >>==14005== by 0x1B8E53EF: _dl_start (in /lib/ld-2.3.5.so) >>==14005== by 0x1B8E47C6: (within /lib/ld-2.3.5.so) >> >>Can anyone point me in the right direction? >> >> >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>from IBM. Find simple to follow Roadmaps, straightforward articles, >>informative Webcasts and more! Get everything you need to get up to >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>_______________________________________________ >>Valgrind-users mailing list >>Val...@li... >>https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >Valgrind-users mailing list >Val...@li... >https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > > > |
|
From: Sergey V. <vs...@al...> - 2005-07-23 11:55:22
|
On Fri, 22 Jul 2005 15:25:22 -0400 Bob Dusek wrote: > ==14005== Signal 11 (SIGSEGV) appears to have lost its siginfo; I can't go on. > ==14005== This may be because one of your programs has consumed your > ==14005== ration of siginfo structures. This looks like a known problem: http://kerneltrap.org/mailarchive/1/message/25599/thread Basically, some program on your system is building up a large queue of pending signals, and this causes the siginfo data for other signals to be dropped (the number of queued signals is limited per user; some older kernels had only a system-wide limit for it). However, Valgrind absolutely needs siginfo for SIGSEGV. A workaround is to track down the offending program and avoid running it while using Valgrind (but this may be hard, given the fact that the kernel does not report the number of queued signals anywhere in /proc). Seems that the problem is finally solved in kernel 2.6.12: http://linux.bkbits.net:8080/linux-2.6/cset@422dec58vwDdDoiI1M3rszWXpJubSw?nav=index.html|src/|src/kernel|related/kernel/signal.c |
|
From: Bob D. <bd...@sr...> - 2005-07-25 14:57:19
|
Thank you, Sergey. That does seem to explain it. You're right though, it may be hard to find the signal offender. I'll try shutting down a couple of apps to see if I can find the culprit. I'm downloading 2.6.12, right now. Thanks again. I appreciate it. Bob On Sat, 2005-07-23 at 15:54 +0400, Sergey Vlasov wrote: > On Fri, 22 Jul 2005 15:25:22 -0400 Bob Dusek wrote: > > > ==14005== Signal 11 (SIGSEGV) appears to have lost its siginfo; I can't go on. > > ==14005== This may be because one of your programs has consumed your > > ==14005== ration of siginfo structures. > > This looks like a known problem: > > http://kerneltrap.org/mailarchive/1/message/25599/thread > > Basically, some program on your system is building up a large queue of > pending signals, and this causes the siginfo data for other signals to > be dropped (the number of queued signals is limited per user; some older > kernels had only a system-wide limit for it). However, Valgrind > absolutely needs siginfo for SIGSEGV. > > A workaround is to track down the offending program and avoid running it > while using Valgrind (but this may be hard, given the fact that the > kernel does not report the number of queued signals anywhere in /proc). > > Seems that the problem is finally solved in kernel 2.6.12: > > http://linux.bkbits.net:8080/linux-2.6/cset@422dec58vwDdDoiI1M3rszWXpJubSw?nav=index.html|src/|src/kernel|related/kernel/signal.c |