Summary: | --db-attach does not work | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Gottfried.Ganssauge |
Component: | memcheck | Assignee: | Tom Hughes <tom> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | vanandel, wefing |
Priority: | NOR | ||
Version: | 2.1.1 | ||
Target Milestone: | --- | ||
Platform: | Unlisted Binaries | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Hack to make db-attach work again
Fix typo in previous patch |
Description
Gottfried.Ganssauge
2004-03-17 12:02:31 UTC
The same behaviour on latest version from CVS (2004-03-24), RedHat 8.0. uname -a: Linux asalwa.osmosys.tv 2.4.25 #2 SMP Tue Mar 2 14:13:26 CET 2004 i686 i686 i386 GNU/Linux I can reproduce this on RedHat 8.0, but not on RedHat 9 or Fedora Core 1. Obviously the ptrace(PTRACE_DETACH, pid, NULL, SIGSTOP) manages to work with those kernels although it isn't obvious why. Then again I can't quite work out from the kernel source how the signal from a PTRACE_CONT or PTRACE_DETACH is every delivered... I can reproduce it on RedHat 9.0 too. (kernel 2.4.24, SMP machine, glibc-2.3.2-27.9). BTW, bug 77851 should be resolved as a duplicate of this one. Well I'm using kernel 2.4.20-24.9smp on an SMP machine and it seems to work for me which is rather odd... *** Bug 77851 has been marked as a duplicate of this bug. *** In the meantime I had to switch my machine. It runs Debian testing with kernel Linux helios 2.4.25-1-686-smp #1 SMP Tue Feb 24 12:07:16 EST 2004 i686 GNU/Linux and libc-2.3.2.ds1 The bug still happens Created attachment 5557 [details]
Hack to make db-attach work again
The problem witdh --db-attach=yes seems to be that in vg_main.c:start_debugger
the child resumes executing after the 'ptrace(PTRACE_DETACH, ...)' call of
the parent (maybe kernel related).
A crude fix for this is sending an additional SIGSTOP befor
calling PTRACE_DETACH (see attached patch).
In message <20040406181117.27139.qmail@ktown.kde.org> you wrote: > The problem witdh --db-attach=yes seems to be that in vg_main.c:start_debugger > the child resumes executing after the 'ptrace(PTRACE_DETACH, ...)' call of > the parent (maybe kernel related). > > A crude fix for this is sending an additional SIGSTOP befor > calling PTRACE_DETACH (see attached patch). Is there any guarantee that doing that will work though? I'm not sure what happens if a process catches a signal while it is stopped in the debugger... I guess the signal will most likely be queued and processed when the debugger continues the process, which is good. The only question then is whether the process can execute at all before the signal is delivered to it. Tom Created attachment 5621 [details]
Fix typo in previous patch
The line
kill(pid, SIGSTOP) == 0 &
should read
kill(pid, SIGSTOP) == 0 &&
Peter
Well applying that actually breaks things on my RH9 system as the child process appears to get two STOP signals, one from the kill and one from the PTRACE_CONT call and valgrind then hangs after you exit the debugger, waiting for the child to exit. Sending SIGCONT to the child lets things continue. CVS commit by thughes: Change the debugger attachment code to send the STOP signal to the forked process before using ptrace() to continue it, instead of asking ptrace to deliver it, as that doesn't seem to work on some versions of linux. CCMAIL: 77824-done@bugs.kde.org M +2 -1 vg_main.c 1.150 --- valgrind/coregrind/vg_main.c #1.149:1.150 @@ -351,5 +351,6 @@ void VG_(start_debugger) ( Int tid ) WIFSTOPPED(status) && WSTOPSIG(status) == SIGSTOP && ptrace(PTRACE_SETREGS, pid, NULL, ®s) == 0 && - ptrace(PTRACE_DETACH, pid, NULL, SIGSTOP) == 0) { + kill(pid, SIGSTOP) == 0 && + ptrace(PTRACE_DETACH, pid, NULL, 0) == 0) { Char pidbuf[15]; Char file[30]; *** Bug 80139 has been marked as a duplicate of this bug. *** It works now on my system. Good work! Works for me, too. Thanks! Stephan |