|
From: Tom H. <to...@co...> - 2006-09-07 15:16:40
|
In message <115...@ok...>
Alex Bennee <ker...@be...> wrote:
>> There is no way to spot writes made by valgrind itself other than
>> by running it under gdb and using the normal gdb watchpoint support.
>
> (gdb) r --smc-check=all dynamite -z config applu < applu.test.in
> Starting program: /usr/local/bin/valgrind --smc-check=all dynamite -z
> config applu < applu.test.in
> ==6286== Memcheck, a memory error detector.
> ==6286== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> ==6286== Using LibVEX rev 1426, a library for dynamic binary
> translation.
> ==6286== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> ==6286== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation
> framework.
> ==6286== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> ==6286== For more details, rerun with: -v
> ==6286==
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000004033d2f66 in ?? ()
> (gdb) x/i $pc
> 0x4033d2f66: mov %ebx,0x0(%r12)
> (gdb) p/x $r12
> $1 = 0x7feffef7c
> (gdb) x/w $1
> 0x7feffef7c: Cannot access memory at address 0x7feffef7c
> (gdb)
>
> Hmmm not a good sign that it doesn't get as far in gdb as running from
> the command line. Now our app does move around in memory, I wonder if
> the combination of Valgrind, Our app and gdb's memory demands are just
> too much to handle?
It is normal for some SEGVs to occur under valgrind - they are caused
by the client program's stack growing beyond it's current limit. They
are caught and fixed up by valgrind though.
See README_DEVELOPERS for instructions on running under gdb.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|