Re: Re:[wxPython] Could "Segmentation faults"...

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Re:[wxPython] Could "Segmentation faults"...

Robin Dunn
> You could register a signal handler to trap SIGSEGV and various other
> bad things and raise an exception. For SIGSEGV, SIGILL and other
> real nasties, it would probably be a very bad thing to pass on
> the exceptions. You're only likely to get these when you're doing
> initial development (or doing dynamic stuff at runtime), ao
> it would be helpfull in identifying the offending call.
>

But if I'm 19 layers deep in gtk code (which BTW sets its own signal handlers
for these) catching the signal and gracefully recovering all the way back up
to my code so I can turn it into a Python exception and then continuing on
without causing other problems is not likley to happen.  Once a segfault or
such happens the program is usually toast.  The best I can do is catch the
signal and report the name of the last wrapper function called and then exit.
While this is marginally better than what is happening now, from a Python
programmer perspective I don't think it helps much...  It's much better to
rebuild wxGTK and wxPython with the debugging flags enabled and let the
toolkit tell you what are doing wrong for many of the problems.

--
Robin Dunn
Software Craftsman
[hidden email]
http://AllDunn.com/robin/
http://AllDunn.com/wxPython/  Check it out!



_______________________________________________
wxPython-users maillist  -  [hidden email]
http://starship.python.net/mailman/listinfo/wxpython-users



Reply | Threaded
Open this post in threaded view
|

Re: Re:[wxPython] Could "Segmentation faults"...

Nicolas Chauvat-2
> > > You could register a signal handler to trap SIGSEGV and various other
> [snip]
> >
> > But if I'm 19 layers deep in gtk code (which BTW sets its own signal handlers
> > for these) catching the signal and gracefully recovering all the way back up
> > to my code so I can turn it into a Python exception and then continuing on
> > without causing other problems is not likley to happen.  Once a segfault or
> > such happens the program is usually toast.  The best I can do is catch the
> > signal and report the name of the last wrapper function called and then exit.
> > While this is marginally better than what is happening now, from a Python
> > programmer perspective I don't think it helps much...  It's much better to
> > rebuild wxGTK and wxPython with the debugging flags enabled and let the
> > toolkit tell you what are doing wrong for many of the problems.
>
> I understand your concern. But from a newbie's perspective, showing the
> last wrapper called is a major help. For example, I've been playing with
> Boa Cunstructor (formerly Pygasm). Since I was a) new to wxWindows, 2)
> new to wxPython, and 3) completely lost in the BOA code, getting
> segmentation faults left me completely clueless about where to look. I
> had to run under pdb by setting set_trace in various places and step
> line by line. It was ALOT of stepping.

Hence, I think that if the only improvement was that on segfault you would
get the last line executed in the python script, it would still be really
useful.

No need to recover and keep on with the execution, no need to raise an
exception depending on what failed. Just the line of the script where the
error happened. Then if I really want to know why it crashed, I can use
the libraries with the debugging information.

But at least, if my mistake is obvious, I can correct it without getting
into the trouble of "breakpointing and stepping".

How could I help ?

-- Nicolas

 (o-  Hi, I'm a deadly e-mail virus, please copy me into your .signature
 /\   file to help me spread. :: Bonjour, je suis un dangereux virus. SVP
Y_/_  copiez-moi dans votre fichier .signature pour m'aider à me propager.    


_______________________________________________
wxPython-users maillist  -  [hidden email]
http://starship.python.net/mailman/listinfo/wxpython-users