Re: libSegFault.so and gcj

Ben Gardiner wrote:
> Andrew Haley wrote:
>>> I reason from this that the segfaults are likely stack overflows. Could
>>> anyone confirm this?
>>>     
>> That's quite possible.  Do you not have a debugger?
>>
>> Clearly if it really is a stack overflow then you're not going to be
>> able to call the null pointer handler.  There is a way around this,
>> though.  If you use the -fstack-check option gcc generates a probe
>> at the start of every method that writes a zero some 12kbytes below
>> the stack pointer.  This will give you enough stack space for the
>> catch_segv handler to run.
> David Daney wrote:
>> Usually if you die with a SIGSEGV, it is due to stack overflow.
>> Probably for one reason or another you are getting a fault during the
>> NullPointerException processing which causes the signal handler to be
>> reentered recursively.  This goes on until the stack overflows and the
>> kernel then kills the process.  If you could attach a debugger to the
>> process, that might shed some light on exactly what is happening.
>> Assuming that it is not normal for your application to take
>> NullPointerExceptions it shouldn't be too tedious.
> Andrew and David, thank you for your insights and for the speed with 
> which they were provided.
> 
> About the debugger; I agree it would be the easiest way to figure out 
> what's going on here. Since I don't know how to reproduce the problem I 
> was hoping to get some information from our devices in the field if and 
> when they die of a segmentation fault.
> 
> Would it be possible -- and if so, are there any significant drawbacks 
> -- to store the previous handler in INIT_SEGV and register it when 
> catch_segv is entered, then re-register catch_segv on the way out? Would 
> this allow the segv signal to be passed up to libSegFault.so's handler 
> when it would have otherwise resulted in a recursive dead-end?
> 

I think it would be very difficult to get that to work.  You would have 
to restore the handler in catch_segv, but where would you reregister 
catch_segv?  Actually I am not sure, but it is in either the java 
personality routine or the unwinder in libgcc.  The problem is:  what do 
you do for a multi-threaded application?  Thread A has to be able to 
handle SIGSEGV while thread B is unwinding its own exceptions.  Making 
sure that there were no race conditions could be difficult.

David Daney