Catching a segfault in a Python library

[MrJean1]

Try catching SIGSEGV using the Python signal module

  <http://docs.python.org/lib/module-signal.html>

An example (for SIGALRM) is on the next page

  <http://docs.python.org/lib/node546.html>

However, it may not work since a SIGSEGV fault is pretty much the end
of everything :-(

/Jean Brouwers



On Nov 24, 6:22 am, Donn Ingle <donn.in... at gmail.com> wrote:
> > I think the idea is, certain fonts in his collection may be corrupt,
> > and he wants to just scan through and load them, ignoring the ones
> > that make the program crash.  
>
> Ya got me! Sheesh, I can't hide anywhere :D
>
> > The bug in this case lies with a third
> > party and isn't something he can easily fix (although he can file
> > reports to the third party (PIL)).
>
> I've a bad memory and can't recall what I told PIL at the time. It might
> have been a case of waiting to see what new versions can do.
>
> > not nice for the application to just crash when that happens, asking
> > them if they want to debug it.  
>
> Zigactly! You can wrap try/except around the calls that (by debugging) you
> know are the culprits, but a segfault is a segfault and bam! you are at the
> command line again.
>
> > I haven't really found a solution,
> > just have tried to prevent corrupted files in the system for now.  Let
> > me know if you get this solved
>
> I'll certainly pop a note. I think, though, that the answer may reside in
> the basic theme of this thread:
>
> runapp
>  result = runActualApp( )
>  while True:
>   if result == allokay: break
>   else:
>    <Start handling the horror>
>
> Unless a segfault goes through that too, like Krypton through Superman.
> \d