Catching a segfault in a Python library

[Donn Ingle]

Yo,
An app of mine relies on PIL. When PIL hits a certain problem font (for
unknown reasons as of now) it tends to segfault and no amount of try/except
will keep my wxPython app alive.

My first thought is to start the app from a bash script that will check the
return value of my wxPython app and could then launch a new app to help the
user grok what happened and fix it.

Do you think that's a good idea, or is there another way to handle stuff
like this? (perhaps a Python app launching another Python app?)

/d

[Paul Rubin]

Donn Ingle <do********@gma il.comwrites:

Do you think that's a good idea, or is there another way to handle stuff
like this? (perhaps a Python app launching another Python app?)

Run your app under a debugger and figure out what is making it crash.

[Donn Ingle]

Run your app under a debugger and figure out what is making it crash.
Already done, the code within PIL is causing the crash. It gets ugly and out
of my remit. It's a freetype/Pil thing and I simply want to a way to catch
it when it happens.
Since a segfault ends the process, I am asking about "wrappers" around code
to catch a segfault.

\d

[Paul Rubin]

Donn Ingle <do********@gma il.comwrites:

Run your app under a debugger and figure out what is making it crash.

Already done, the code within PIL is causing the crash. It gets ugly and out
of my remit. It's a freetype/Pil thing and I simply want to a way to catch
it when it happens.
Since a segfault ends the process, I am asking about "wrappers" around code
to catch a segfault.

Well I think you should actually debug it, or at least reproduce it
and send a bug report to the PIL folks, but anyway you can use
os.wait() to get the exit status and recognize the seg fault.

[Donn Ingle]

Well I think you should actually debug it, or at least reproduce it

and send a bug report to the PIL folks,

It was a while ago, and if memory serves I did that, but memory fails.

but anyway you can use
os.wait() to get the exit status and recognize the seg fault.

Okay, that's a good start. Thanks, I'll go for a python starts wxpython
thing with os.wait() to sniff the outcome.
\d

[Paul Rubin]

Donn Ingle <do********@gma il.comwrites:

Okay, that's a good start. Thanks, I'll go for a python starts wxpython
thing with os.wait() to sniff the outcome.

You may have to roll your own fork/exec to start the wxpython, instead
of using popen or the subprocess module. I'm not terribly conversant
in those modules but they may start a shell which would isolate your
program from the wxpython exit code.

[Donn Ingle]

You may have to roll your own fork/exec to start the wxpython, instead

of using popen or the subprocess module. Â*I'm not terribly conversant
in those modules but they may start a shell which would isolate your
program from the wxpython exit code.

Hrmm... Neither am I, that's why I asked here :) But I'll skin that Python
when I get to it.

Thanks.
\d

[Ayaz Ahmed Khan]

Donn Ingle wrote:

Already done, the code within PIL is causing the crash. It gets ugly and
out of my remit. It's a freetype/Pil thing and I simply want to a way to
catch it when it happens.
Since a segfault ends the process, I am asking about "wrappers" around
code
to catch a segfault.

\d

Wouldn't it be better to narrow down to what in your code is invoking PIL
in a manner in which PIL exhibits such behaviour, and handle it within
your code?

Just a thought!

--
Ayaz Ahmed Khan

[Patrick Mullen]

On 24 Nov 2007 08:41:24 GMT, Ayaz Ahmed Khan <ay**@dev.nullw rote:

Donn Ingle wrote:

Already done, the code within PIL is causing the crash. It gets ugly and
out of my remit. It's a freetype/Pil thing and I simply want to a way to
catch it when it happens.
Since a segfault ends the process, I am asking about "wrappers" around
code
to catch a segfault.

\d

Wouldn't it be better to narrow down to what in your code is invoking PIL
in a manner in which PIL exhibits such behaviour, and handle it within
your code?

Just a thought!

--
Ayaz Ahmed Khan

--
http://mail.python.org/mailman/listinfo/python-list

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. 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)).

This has come up for me as well with loading meshes in a 3d
application. The user or someone may include a corrupt file, and it's
not nice for the application to just crash when that happens, asking
them if they want to debug it. 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 :)

[Donn Ingle]

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