This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
>>movl    %%esp,%%ebp
>>addl    $36,%%ebp
>>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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]