This is the mail archive of the
mailing list for the Cygwin project.
Re: Signal handling tune up.
At 11:55 AM 8/29/2003 -0400, you wrote:
>On Fri, Aug 29, 2003 at 10:19:22AM -0400, Pierre A. Humblet wrote:
>>Christopher Faylor wrote:
>>>I was heartened to see that zsh did not crash when I sicc'ed this
>>>program on it -- until I tried to type something at the zsh prompt and
>>>saw that it was hung. The reason was that the recursive signal call
>>>stuff was still not right. We were restoring the return address
>>>incorrectly. AFAICT, we really do have to use the stored
>>>retaddr_on_stack to rectify setup_handler's inappropriate "fixup" of
>>>the return address. Restoring it to 36(%%esp) wasn't right.
>>Wow. What was wrong? After you noticed that one could remove
>>before the call to set_process_mask, I though eveything made perfect
>>sense. After returning from the (user) signal handler and pulling off
>>the argument, both the esp and ebp should be exactly as before the
>>call. It that's not true, the whole stack model of programming breaks
>The code that was there put the return address of the nested call onto the
>stack for the return of the initial signal handler. I just changed it
>to mimic what call_signal_handler_now does.
FWIW, I have identified the error in my reasoning.
I was assuming the return address from the initial handler to be
"interruptible" (makes sense, otherwise the handler shouldn't have started
When it is, retaddr_on_stack is identical to esp + 36 and the code was OK.
However there is one case where it is not: when the handler is called
by sigframe::call_signal_handler from sig_dispatch_pending.