|
From: Eyal L. <ey...@ey...> - 2005-01-20 00:32:47
|
Jeremy Fitzhardinge wrote: > On Thu, 2005-01-20 at 10:07 +1100, Eyal Lebedinsky wrote: > >>I get this report from a run: >> >>==2005-01-20 08:04:14.204 32619== Thread 9: >>==2005-01-20 08:04:14.220 32619== Syscall param socketcall.send(msg) points to uninitialised byte(s) >>==2005-01-20 08:04:14.220 32619== at 0x1C043A8E: send (in /lib/tls/libpthread-0.60.so) >>==2005-01-20 08:04:14.220 32619== Address 0x219C9749 is 57 bytes inside a block of size 12288 alloc'd >>==2005-01-20 08:04:14.220 32619== at 0x1B906FE5: calloc (vg_replace_malloc.c:175) >> >>I know that I am sending uninitialised data, but in the past I got >>a proper stack trace rather than just the 'send' message. Even the >>'calloc' message, without a stack, is not so helpful. >> >>Am I missing a new option? or is there a reason for this change? > > > I think libpthread is compiled with -fomit-frame-pointer, which makes it > hard to get good stack traces. I'm thinking about experimenting with > libunwind to see if we can use it for stack traces; it understands the > unwind info that gcc puts into new .o files, which should make it > possible to get good backtraces in these cases. > > I'm not sure why calloc isn't getting a bit more backtrace. Make sure > there are no -fomit-frame-pointers in the Valgrind makefiles. For vg I do a different build than normal. I build with '-O0' and nothing else (just some extra warn requests): -W -Wall -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wconversion -Wredundant-decls -ansi -D_XOPEN_SOURCE=1 -D_GNU_SOURCE=1 -O0 -fno-inline -g I should say I used to get the trace, this laconic report is recent. > Oh, and that you're not using --num-callers=1. I use '--num-callers=32' which I find good enough. > J -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> If attaching .zip rename to .dat |