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?)
Run your app under a debugger and figure out what is making it crash.
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.
> 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.
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.
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
Just a thought!
Ayaz Ahmed Khan
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 :)
> 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( )
if result == allokay: break
<Start handling the horror>
Unless a segfault goes through that too, like Krypton through Superman.
No you can't do it that way, when I say "run it under a debugger", I
mean run the entire Python interpreter under something like gdb, and
actually debug the seg fault. I can understand if you're reluctant to
make that effort. If it's for something critical then you should
certainly do it. If it's for something exposed to the internet or
used by potentially malicious users then you should certainly do it.
If it's for something throwaway and exposed only to trusted users,
then maybe your trap-and-restart approach can keep things usable for a
This is mainly because I lack the skills to hack deeply into complex stuff
like PIL, even though a lot of it is Python, and also because the goals
keep changing as new versions of libs like PIL and Freetype come out. I'd
rather have a parachute than a scalpel :)
If I can just write a "BLOODYHELL" flag to a text file and then let it all
crash, the next time the app is run, it can go into "Dude, we have
Unfortunately this does not work for SIGSEGV: "Because the C signal
handler always returns, it makes little sense to catch synchronous
errors like SIGFPE or SIGSEGV"
The best approach I have seen for doing this the proper way is a bit
Also, do a Google search for "libwadpy".
This project needs reviving. Once I start full time in January I may
devote some time to this. Also, I have a friend in need of a computer
science senior project who may help.
The general question is why not build this directly into the
interpreter? The interpreter can automatically raise a seg fault
exception when SIGSEGV occurs. Easier said then done, but why not?