>From our discussion yesterday, ...
On Fri, Jul 15, 2005 at 05:36:34PM +0200, Bodo Stroesser wrote:
> So I thought about avoiding the sigreturn at all. Working on
> this I found out some small points:
I kept this patch
> - there is a bug (typo) in wait_stub_done()
but dropped these two, plus my dont-save-fpregs patch. Correct?
> - stopping stub_segv_handler with a "breakpoint" without
> calling sigreturn, lets SIGSEGV being blocked after that.
> At the next SIGSEGV, I see stub_wait_done() calling panic
> just as with Rob's problem. And I see the child being gone!
> I understand, that the host unblocks SIGSEGV and sets the
> handler to SIG_DFL. But I don't understand, why the child
> already is gone after the waitpid(), without resuming it.
> I guess, this is the reason for Rob not being able to debug
> the problem.
> Thus I added SA_NOMASK to the flags for the handler.
>
> - I changed the additional mask for the handler to be empty.
> The only exception is x86_64, that currently must use sigreturn
> and therefore still masks SIGUSR1 while the handler runs.
> In skas, userspace shouldn't receive SIGIO or SIGWINCH (I hope
> I'm right here?), SIGVTALRM already is handled by wait_stub_done.
> Then I changed i386's stub_segv_handler to stop using "int3"
> immediately after saving faultinfo.
> This new method saves some syscalls on i386 and s390 and
> simplifies s390.
Jeff
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
