|
From: Oswald B. <os...@kd...> - 2004-03-05 14:39:33
|
moin, using the following command line: valgrind --tool=memcheck --num-callers=8 --db-attach=yes ./<my-program & args> i get the following result when vg detects an error: ------------- [error report] ==5924== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y starting debugger ==5924== starting debugger with cmd: /usr/bin/gdb -nw /proc/5926/fd/822 5926 valgrind: vg_signals.c:1587 (vg_sync_signalhandler): Assertion `info->si_code <= 0' failed. ==5926== at 0xB802F790: vgPlain_skin_assert_fail (vg_mylibc.c:1211) ==5926== by 0xB802F78F: assert_fail (vg_mylibc.c:1207) ==5926== by 0xB802F7FD: vgPlain_core_assert_fail (vg_mylibc.c:1218) ==5926== by 0xB8035E81: vg_sync_signalhandler (vg_signals.c:1630) ==5926== by 0xB80CE1F3: ??? sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 [client bt] [help text] GNU gdb 6.0 [gdb stuff] /proc/5926/fd/822: Permission denied. Attaching to process 5926 ptrace: Operation not permitted. /home/ossi/src/isync/isync.exp1/src/5926: No such file or directory. (gdb) ------------ obviously, i can't do anything useful in gdb. when i quit, vg continues correctly. greetings [cc: me!] -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Tom H. <th...@cy...> - 2004-03-05 15:23:14
|
In message <20040305143245.GA5946@ugly.local>
Oswald Buddenhagen <os...@kd...> wrote:
> valgrind --tool=memcheck --num-callers=8 --db-attach=yes ./<my-program & args>
>
> i get the following result when vg detects an error:
> -------------
>
> [error report]
> ==5924== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
> starting debugger
> ==5924== starting debugger with cmd: /usr/bin/gdb -nw /proc/5926/fd/822 5926
>
> valgrind: vg_signals.c:1587 (vg_sync_signalhandler): Assertion `info->si_code <= 0' failed.
> ==5926== at 0xB802F790: vgPlain_skin_assert_fail (vg_mylibc.c:1211)
> ==5926== by 0xB802F78F: assert_fail (vg_mylibc.c:1207)
> ==5926== by 0xB802F7FD: vgPlain_core_assert_fail (vg_mylibc.c:1218)
> ==5926== by 0xB8035E81: vg_sync_signalhandler (vg_signals.c:1630)
> ==5926== by 0xB80CE1F3: ???
When attaching to the debugger valgrind clones the process with fork
and then asks the debugger to attach to that copy of the process. It
looks like for some reason on your system that forked copy is catching
a fatal signal (either SEGV, BUS, FPE or ILL) which is causing the
signal handler to go a bit mad.
The question is why are you getting that signal? all the forked
process does it a ptrace call followed by sending SIGSTOP to itself
to prevent any further execution. Perhaps your kernel is failing to
honour the SIGSTOP properly or something?
> [gdb stuff]
> /proc/5926/fd/822: Permission denied.
>
> Attaching to process 5926
> ptrace: Operation not permitted.
> /home/ossi/src/isync/isync.exp1/src/5926: No such file or directory.
> (gdb)
Not surprising when process 5926 has caught a fatal signal and died ;-)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Oswald B. <os...@kd...> - 2004-03-20 16:12:09
|
On 2004-03-05 16:23, Tom Hughes wrote: > When attaching to the debugger valgrind clones the process with fork and > then asks the debugger to attach to that copy of the process. It looks > like for some reason on your system that forked copy is catching a fatal > signal (either SEGV, BUS, FPE or ILL) which is causing the signal > handler to go a bit mad. > > The question is why are you getting that signal? all the forked process > does it a ptrace call followed by sending SIGSTOP to itself to prevent > any further execution. Perhaps your kernel is failing to honour the > SIGSTOP properly or something? > ok, i had a look at the code ... the SIGSTOP passed to PTRACE_DETACH is bogus; the data item is the exit code to inject in case the process exited - or something like that. it works if i send the process a SIGSTOP after the PTRACE_DETACH. this can work, as the child is not scheduled immediately, but it is inherently racy. an alternative would be injecting a stackframe and setting the instruction pointer on a pause() call followed by a function epilogue (or better, by some fatal termination, as continuing won't work anyway) ... greetings -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Tom H. <th...@cy...> - 2004-03-20 18:18:33
|
In message <20040320161201.GA3896@ugly.local>
Oswald Buddenhagen <os...@kd...> wrote:
> the SIGSTOP passed to PTRACE_DETACH is bogus; the data item is the exit
> code to inject in case the process exited - or something like that.
You may be right that SIGSTOP doesn't work, but that appears to be
because it is a special case.
The manual page ptrace says that PTRACE_DETACH restarts the child
as for PTRACE_CONT after having first detached. For PTRACE_CONT it
says that the data argument is delivered as a signal. The only
problem is that it says SIGSTOP is an exception to that.
That said, the technique we are currently using works on all the
machines I have tried it on or it wouldn't be there.
> it works if i send the process a SIGSTOP after the PTRACE_DETACH. this
> can work, as the child is not scheduled immediately, but it is
> inherently racy.
As you say, that is an out and out race condition so can't really
be used as it would never be reliable.
> an alternative would be injecting a stackframe and
> setting the instruction pointer on a pause() call followed by a function
> epilogue (or better, by some fatal termination, as continuing won't work
> anyway) ...
Playing with EIP is not possible either as it defeats the whole
object of the change to this new technique for attaching the
debugger, which was to ensure that the debugger saw the real
state of the process.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Oswald B. <os...@kd...> - 2004-03-20 18:43:45
|
On Sat, Mar 20, 2004 at 06:18:34PM +0000, Tom Hughes wrote: > The manual page ptrace says that PTRACE_DETACH restarts the child > as for PTRACE_CONT after having first detached. For PTRACE_CONT it > says that the data argument is delivered as a signal. The only > problem is that it says SIGSTOP is an exception to that. > oh, indeed, reading the entire man page is more effective than reading parts of highly cryptic kernel sources. :) > That said, the technique we are currently using works on all the > machines I have tried it on or it wouldn't be there. > strange, huh? anybody on debian unstable with linux 2.4.25? > > an alternative would be injecting a stackframe and setting the > > instruction pointer on a pause() call followed by a function > > epilogue (or better, by some fatal termination, as continuing won't > > work anyway) ... > > Playing with EIP is not possible either as it defeats the whole object > of the change to this new technique for attaching the debugger, which > was to ensure that the debugger saw the real state of the process. > guess why i suggested to inject a stack frame ... greetings -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Doug R. <df...@nl...> - 2004-03-20 19:02:33
|
On Saturday 20 March 2004 18:18, Tom Hughes wrote: > In message <20040320161201.GA3896@ugly.local> > > Oswald Buddenhagen <os...@kd...> wrote: > > the SIGSTOP passed to PTRACE_DETACH is bogus; the data item is the > > exit code to inject in case the process exited - or something like > > that. > > You may be right that SIGSTOP doesn't work, but that appears to be > because it is a special case. > > The manual page ptrace says that PTRACE_DETACH restarts the child > as for PTRACE_CONT after having first detached. For PTRACE_CONT it > says that the data argument is delivered as a signal. The only > problem is that it says SIGSTOP is an exception to that. > > That said, the technique we are currently using works on all the > machines I have tried it on or it wouldn't be there. > > > it works if i send the process a SIGSTOP after the PTRACE_DETACH. > > this can work, as the child is not scheduled immediately, but it is > > inherently racy. > > As you say, that is an out and out race condition so can't really > be used as it would never be reliable. > > > an alternative would be injecting a stackframe and > > setting the instruction pointer on a pause() call followed by a > > function epilogue (or better, by some fatal termination, as > > continuing won't work anyway) ... > > Playing with EIP is not possible either as it defeats the whole > object of the change to this new technique for attaching the > debugger, which was to ensure that the debugger saw the real > state of the process. How about just implementing something which talks gdb's remote debugging protocol (which is dead simple) and letting gdb attach to valgrind via tcp/ip. |