|
From: Jeroen N. W. <jn...@xs...> - 2005-08-26 17:30:50
|
Just for a lark, I ran the program in my previous post under valgrind/memcheck 3.1.SVN. Unfortunately, this shows a possible problem in valgrind: the output of the printf on line 16 is produced twice. The output of valgrind -v appears below. Also unfortunately, I cannot get gdb to do useful things with the core produced under valgrind. Jeroen. ==3079== Memcheck, a memory error detector. ==3079== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==3079== Using LibVEX rev 1362M, a library for dynamic binary translation. ==3079== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==3079== Using valgrind-3.1.SVN, a dynamic binary instrumentation framework. ==3079== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. --3079-- Valgrind library directory: /home/jeroen/MirrorDirs/valgrind-testing/.in_place --3079-- Command line --3079-- ./makecoredump --3079-- Startup, with flags: --3079-- --command-line-only=yes --3079-- -v --3079-- --tool=memcheck --3079-- Contents of /proc/version: --3079-- Linux version 2.4.26-1-386 (horms@tabatha) (gcc version 3.2.3 (Debian)) #1 Tue Aug 24 13:31:19 JST 2004 --3079-- Reading syms from /home/jeroen/SourceDirs/miscellaneous/makecoredump/makecoredump (0x8048000) --3079-- Reading syms from /lib/ld-2.3.2.so (0x1B8E4000) --3079-- Reading debug info from /lib/ld-2.3.2.so... --3079-- ... CRC mismatch (computed E7117123 wanted 4ECF6D33) --3079-- object doesn't have a symbol table --3079-- Reading syms from /home/jeroen/MirrorDirs/valgrind-testing/coregrind/stage2 (0xB0000000) --3079-- Reading suppressions file: /home/jeroen/MirrorDirs/valgrind-testing/.in_place/default.supp ==3079== --3079-- Reading syms from /home/jeroen/MirrorDirs/valgrind-testing/coregrind/vgpreload_core.so (0x1B8FC000) --3079-- Reading syms from /home/jeroen/MirrorDirs/valgrind-testing/memcheck/vgpreload_memcheck.so (0x1B8FE000) --3079-- Reading syms from /lib/libc-2.3.2.so (0x1B912000) --3079-- Reading debug info from /lib/libc-2.3.2.so... --3079-- ... CRC mismatch (computed 76EC50B6 wanted 52619D67) --3079-- object doesn't have a symbol table --3079-- Reading syms from /lib/libdl-2.3.2.so (0x1BA45000) --3079-- Reading debug info from /lib/libdl-2.3.2.so... --3079-- ... CRC mismatch (computed 6F61513E wanted 280D08E5) --3079-- object doesn't have a symbol table --3079-- REDIR: 0x1B987FD0 (rindex) redirected to 0x1B901530 (rindex) ==3080== ==3080== Process terminating with default action of signal 3 (SIGQUIT): dumping core ==3080== at 0x1B93B7C1: kill (in /lib/libc-2.3.2.so) ==3080== by 0x804840E: dump_core (makecoredump.c:9) ==3080== by 0x8048431: main (makecoredump.c:17) About to dump ... done. About to dump ...--3080-- REDIR: 0x1B9830E0 (free) redirected to 0x1B900611 (free) ==3080== ==3080== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 16 from 1) --3080-- --3080-- supp: 16 Ugly strchr error in /lib/ld-2.3.2.so ==3080== malloc/free: in use at exit: 0 bytes in 0 blocks. ==3080== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==3080== ==3080== No malloc'd blocks -- no leaks are possible. --3080-- memcheck: sanity checks: 0 cheap, 1 expensive --3080-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --3080-- memcheck: auxmaps: 0 searches, 0 comparisons --3080-- memcheck: secondaries: 9 issued (576k, 0M) --3080-- memcheck: secondaries: 17 accessible and distinguished (1088k, 1M) --3080-- tt/tc: 3304 tt lookups requiring 3349 probes --3080-- tt/tc: 3304 fast-cache updates, 2 flushes --3080-- translate: new 1652 (33593 -> 549152; ratio 163:10) [0 scs] --3080-- translate: dumped 0 (0 -> ??) --3080-- translate: discarded 0 (0 -> ??) --3080-- scheduler: 33053 jumps (bb entries). --3080-- scheduler: 0/1801 major/minor sched events. --3080-- sanity: 1 cheap, 1 expensive checks. --3080-- exectx: 4999 lists, 8 contexts (avg 0 per list) --3080-- exectx: 16 searches, 8 full compares (500 per 1000) --3080-- exectx: 0 cmp2, 44 cmp4, 0 cmpAll --3079-- REDIR: 0x1B9830E0 (free) redirected to 0x1B900611 (free) ==3079== ==3079== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 16 from 1) --3079-- --3079-- supp: 16 Ugly strchr error in /lib/ld-2.3.2.so ==3079== malloc/free: in use at exit: 0 bytes in 0 blocks. ==3079== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==3079== ==3079== No malloc'd blocks -- no leaks are possible. --3079-- memcheck: sanity checks: 0 cheap, 1 expensive --3079-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --3079-- memcheck: auxmaps: 0 searches, 0 comparisons --3079-- memcheck: secondaries: 9 issued (576k, 0M) --3079-- memcheck: secondaries: 17 accessible and distinguished (1088k, 1M) --3079-- tt/tc: 3528 tt lookups requiring 3571 probes --3079-- tt/tc: 3528 fast-cache updates, 2 flushes --3079-- translate: new 1764 (35368 -> 579692; ratio 163:10) [0 scs] --3079-- translate: dumped 0 (0 -> ??) --3079-- translate: discarded 0 (0 -> ??) --3079-- scheduler: 33985 jumps (bb entries). --3079-- scheduler: 0/1912 major/minor sched events. --3079-- sanity: 1 cheap, 1 expensive checks. --3079-- exectx: 4999 lists, 8 contexts (avg 0 per list) --3079-- exectx: 16 searches, 8 full compares (500 per 1000) --3079-- exectx: 0 cmp2, 44 cmp4, 0 cmpAll |
|
From: Nicholas N. <nj...@cs...> - 2005-08-26 18:16:27
|
On Fri, 26 Aug 2005, Jeroen N. Witmond wrote: > Just for a lark, I ran the program in my previous post under > valgrind/memcheck 3.1.SVN. Unfortunately, this shows a possible problem in > valgrind: the output of the printf on line 16 is produced twice. The > output of valgrind -v appears below. I think what Valgrind is doing is ok. Your printf() call doesn't end in a newline and so the output doesn't have to be flushed to stdout immediately. As a result, it's still sitting in the printf buffer when the fork occurs. And then it subsequently gets flushed in the parent and the child. If you add a newline to the printf() call, or call fflush(stdout) after the printf() call, the string only gets printed once when run under Valgrind. > Also unfortunately, I cannot get gdb to do useful things with the core > produced under valgrind. Valgrind's core-dumping code got disabled in the 2.x-to-3.x transition because it had lots of x86-specific code, and it hasn't been reenabled yet. It would be a good project for someone who's feeling motivated. Nick |
|
From: Jeroen N. W. <jn...@xs...> - 2005-08-26 18:46:58
|
> On Fri, 26 Aug 2005, Jeroen N. Witmond wrote: > >> Just for a lark, I ran the program in my previous post under >> valgrind/memcheck 3.1.SVN. Unfortunately, this shows a possible problem >> in >> valgrind: the output of the printf on line 16 is produced twice. The >> output of valgrind -v appears below. > > I think what Valgrind is doing is ok. Your printf() call doesn't end in a > newline and so the output doesn't have to be flushed to stdout > immediately. As a result, it's still sitting in the printf buffer when > the fork occurs. And then it subsequently gets flushed in the parent and > the child. > I am not sure I understand. The parent should flush the buffer, and does, as the text 'done.' is produced. The child is told to SIGQUIT (dump core and terminate), and should die immediatelly. When running outside of valgrind it does. Are you saying that the flushing of the child's buffer is an artifact introduced by valgrind? ;-) > If you add a newline to the printf() call, or call fflush(stdout) after > the printf() call, the string only gets printed once when run under > Valgrind. > Correct. Jeroen. |
|
From: Nicholas N. <nj...@cs...> - 2005-08-26 18:57:40
|
On Fri, 26 Aug 2005, Jeroen N. Witmond wrote: > I am not sure I understand. The parent should flush the buffer, and does, > as the text 'done.' is produced. The child is told to SIGQUIT (dump core > and terminate), and should die immediatelly. Why can't the child flush the buffer before dying? Maybe it flushes it immediately after the fork(). AIUI, there's a point at which the buffer must be flushed, but it can be legitimately flushed at any time prior to that. > Are you saying that the flushing of the child's buffer is an artifact > introduced by valgrind? ;-) I'm saying that things sometimes behave differently under Valgrind, but I think in this case the different behaviour is quite valid. N |
|
From: Jeroen N. W. <jn...@xs...> - 2005-08-26 19:12:01
|
> On Fri, 26 Aug 2005, Jeroen N. Witmond wrote: > >> I am not sure I understand. The parent should flush the buffer, and >> does, >> as the text 'done.' is produced. The child is told to SIGQUIT (dump core >> and terminate), and should die immediatelly. > > Why can't the child flush the buffer before dying? Maybe it flushes it > immediately after the fork(). AIUI, there's a point at which the buffer > must be flushed, but it can be legitimately flushed at any time prior to > that. > >> Are you saying that the flushing of the child's buffer is an artifact >> introduced by valgrind? ;-) > > I'm saying that things sometimes behave differently under Valgrind, but I > think in this case the different behaviour is quite valid. > You are correct. Thanks for your explanation. :-) Jeroen. |
|
From: Nicholas N. <nj...@cs...> - 2005-08-26 20:49:09
|
On Fri, 26 Aug 2005, Jeroen N. Witmond wrote: > Thanks for your explanation. :-) You're welcome. It's nice to get one right every once in a while :) Nick |