Catching a segfault in a Python library
MrJean1 at gmail.com
Sat Nov 24 20:49:39 CET 2007
Try catching SIGSEGV using the Python signal module
An example (for SIGALRM) is on the next page
However, it may not work since a SIGSEGV fault is pretty much the end
of everything :-(
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:
> result = runActualApp( )
> while True:
> if result == allokay: break
> <Start handling the horror>
> Unless a segfault goes through that too, like Krypton through Superman.
More information about the Python-list