For example, have that: ----8<---- int main(void) { int c; return c ? 0 : -1; } ---->8---- $ valgrind --db-attach=yes ./a.out < /dev/null ==30353== Memcheck, a memory error detector ==30353== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==30353== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==30353== Command: ./a.out ==30353== ==30353== Conditional jump or move depends on uninitialised value(s) ==30353== at 0x40049E: main (in /home/madcoder/a.out) ==30353== ==30353== ==30353== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- ==30353== ==30353== HEAP SUMMARY: ==30353== in use at exit: 0 bytes in 0 blocks ==30353== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==30353== ==30353== All heap blocks were freed -- no leaks are possible ==30353== ==30353== For counts of detected and suppressed errors, rerun with: -v ==30353== Use --track-origins=yes to see where uninitialised values come from ==30353== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4) The debugger isn't actually started because stdin is "empty" already (and if it wasn't it would be re-read by gdb which is even worse). valgrind should wrap calling the debugger recreating sensible std{in,out,err} using /dev/tty. FWIW this is Debian bug #351823 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351823)
> ==30353== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- ==30353== > ==30353== HEAP SUMMARY: > ==30353== in use at exit: 0 bytes in 0 blocks > ==30353== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > ==30353== > ==30353== All heap blocks were freed -- no leaks are possible > ==30353== > ==30353== For counts of detected and suppressed errors, rerun with: -v > ==30353== Use --track-origins=yes to see where uninitialised values come from > ==30353== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4) > > The debugger isn't actually started because stdin is "empty" already (and if it > wasn't it would be re-read by gdb which is even worse). > > valgrind should wrap calling the debugger recreating sensible std{in,out,err} > using /dev/tty. > > FWIW this is Debian bug #351823 > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351823) > This might be the same as https://bugs.kde.org/show_bug.cgi?id=263423 I have a patch in this bugzilla (dont know if it still applies), can you check? Christian
On Tue, May 10, 2011 at 02:57:15PM +0200, Christian Borntraeger wrote: > https://bugs.kde.org/show_bug.cgi?id=272938 > > > > > > --- Comment #1 from Christian Borntraeger <borntraeger de ibm com> 2011-05-10 14:57:14 --- > > ==30353== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- ==30353== > > ==30353== HEAP SUMMARY: > > ==30353== in use at exit: 0 bytes in 0 blocks > > ==30353== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > > ==30353== > > ==30353== All heap blocks were freed -- no leaks are possible > > ==30353== > > ==30353== For counts of detected and suppressed errors, rerun with: -v > > ==30353== Use --track-origins=yes to see where uninitialised values come from > > ==30353== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4) > > > > The debugger isn't actually started because stdin is "empty" already (and if it > > wasn't it would be re-read by gdb which is even worse). > > > > valgrind should wrap calling the debugger recreating sensible std{in,out,err} > > using /dev/tty. > > > > FWIW this is Debian bug #351823 > > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351823) > > > > This might be the same as > https://bugs.kde.org/show_bug.cgi?id=263423 > I have a patch in this bugzilla (dont know if it still applies), can you check? It's likely to be the same underlying issue indeed, and the patch still applies (with fuzz) I'll try to see if that fixes the issue for me.
On Tue, May 10, 2011 at 03:08:54PM +0200, Pierre Habouzit wrote: > On Tue, May 10, 2011 at 02:57:15PM +0200, Christian Borntraeger wrote: > > https://bugs.kde.org/show_bug.cgi?id=272938 > > > > > > > > > > > > --- Comment #1 from Christian Borntraeger <borntraeger de ibm com> 2011-05-10 14:57:14 --- > > > ==30353== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- ==30353== > > > ==30353== HEAP SUMMARY: > > > ==30353== in use at exit: 0 bytes in 0 blocks > > > ==30353== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > > > ==30353== > > > ==30353== All heap blocks were freed -- no leaks are possible > > > ==30353== > > > ==30353== For counts of detected and suppressed errors, rerun with: -v > > > ==30353== Use --track-origins=yes to see where uninitialised values come from > > > ==30353== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4) > > > > > > The debugger isn't actually started because stdin is "empty" already (and if it > > > wasn't it would be re-read by gdb which is even worse). > > > > > > valgrind should wrap calling the debugger recreating sensible std{in,out,err} > > > using /dev/tty. > > > > > > FWIW this is Debian bug #351823 > > > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351823) > > > > > > > This might be the same as > > https://bugs.kde.org/show_bug.cgi?id=263423 > > I have a patch in this bugzilla (dont know if it still applies), can you check? > > It's likely to be the same underlying issue indeed, and the patch still > applies (with fuzz) > > I'll try to see if that fixes the issue for me. Okay it appears it's not the same issue as your patch doesn't change anything.
(In reply to comment #3) > Okay it appears it's not the same issue as your patch doesn't change > anything. Instead of using --db-attach=yes, you could use gdb and the gdbserver that has recently be integrated in Valgrind svn. (i.e. use --vgdb-error=1 and then connect from gdb when needed).
The --db-attach feature is deprecated as of valgrind 3.10.0. It will be removed in the next valgrind feature release. The built-in GDB server capabilities are superior and should be used instead. Therefore, this bug will not be fixed.