«

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

Donn Ingle <> writes:
> 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.

> 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

Donn Ingle <> writes:
> > 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.

> 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

Donn Ingle <> writes:
> 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.

> 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

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

On 24 Nov 2007 08:41:24 GMT, Ayaz Ahmed Khan <> wrote:
> 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

> 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

> 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