[Pyobjc-dev] A better way to deal w/sig 10 & 11 exceptions

[<bb...@ma...>]

On Tuesday, Jun 3, 2003, at 21:09 US/Eastern, Ben Golding wrote:
> Also, is there a better way to debug problems causing sig 10 or 11 
> than attaching via to the process with gdb and checking the stack 
> trace?  It'd even be nice if you could launch a pyobjc app from 
> ProjectBuilder under the debugger and look at the stack trace there.  
> At present when you do that, it complains about missing stack frames.

The problem is that we have to bootstrap the Python executable via 
execve() and, as such, the original binary image is effectively lost.  
Gdb becomes very confused.

In any case, the ObjC stack is of value-- but not a huge amount as most 
of the frames will be in Apple internal API anyway.

But there is now a better way to deal with sig 10/11.   I added a 
Signals module to PyObjCTools.  When installed as follows....

from PyObjCTools import Signals
Signals.dumpStackOnFatalSignal()

... it will trap all fatal signals-- all signals that normally cause a 
core dump-- and attempt to dump the python stack before reverting the 
signal handler back to the default handler and resignaling.

I.e. if you invoke the above code and then your app crashes with 
SIGBUS, it will dump the Python stack trace before croaking entirely.

It is likely an improvement, anyway...

b.bum