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 <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
