Turning a SIGSEGV into a regular function call under Linux, allowing throw

Steven Schveighoffer schveiguy at yahoo.com
Wed Mar 14 14:35:04 PDT 2012


On Wed, 14 Mar 2012 17:25:28 -0400, deadalnix <deadalnix at gmail.com> wrote:

> Le 14/03/2012 21:53, Steven Schveighoffer a écrit :
>> On Wed, 14 Mar 2012 16:45:49 -0400, Don Clugston <dac at nospam.com> wrote:
>>
>>> On 14/03/12 21:31, Steven Schveighoffer wrote:
>>>> On Wed, 14 Mar 2012 16:08:29 -0400, Don Clugston <dac at nospam.com>  
>>>> wrote:
>>>>
>>>>> Now, your user space handler will cause another segfault when it does
>>>>> the mov [ESP], 0. I think that gives you an infinite loop.
>>>>
>>>> SEGFAULT inside a SEGV signal handler aborts the program (no way to  
>>>> turn
>>>> this off IIRC).
>>>>
>>>> -Steve
>>>
>>> But you're not inside the signal handler when it happens. You returned.
>>
>> Then how does the signal handler do anything? I mean, doesn't it need a
>> stack? Or does it just affect register variables? Most signal handlers
>> are normal functions, and isn't there some usage of the stack to save
>> registers?
>>
>> It seems there should be a way to turn off the signal handler during the
>> time when you are suspicous of the stack being the culprit, then
>> re-engage the signal handler before throwing the error.
>>
>> -Steve
>
> The address of the instruction being executed is hijacked, so, instead  
> of resuming normal operation after the signal handler exit, it get into  
> the throwing handler.
>
> This is a very nice trick !

I get that.  What I was saying is, I thought even the signal handler uses  
the stack (thereby it would abort if invalid).  And even if it doesn't,  
simply accessing the stack by loading it into a register should be  
sufficient to "test" and see if the stack is valid to use (i.e. cause  
another SEGV inside the signal handler forcing an abort so we don't have  
an infinite loop).

I honestly don't know enough to really be discussing, but it seems like a  
really neat idea, and I grasp how it works.  I just don't know all the  
particulars of signal calling conventions.

-Steve


More information about the Digitalmars-d mailing list