[Python-Dev] Need to hook Py_FatalError

Josiah Carlson jcarlson at uci.edu
Tue May 3 20:34:52 CEST 2005


"m.u.k" <m.u.k.2 at gawab.com> wrote:
> 
> Hi,
> 
> Guido van Rossum <gvanrossum at gmail.com> wrote in
> news:ca471dc205050309156962d3ff at mail.gmail.com: 
>  
> > Your efforts would be better directed towards fixing the causes of the
> > fatal errors.
> >
> > I see no need to hook Py_FatalError, but since it's open source, you
> > are of course free to patch your own copy if your urge is truly
> > irresistible. Or I guess you could run Python under supervision of gdb
> > and trap it that way.
> 
> Well, I admit it is a bit triva(as its implementation), at least nobody 
> wanted it within Python's 10+ lifetime. Indeed Im using my own patched copy,
> I just thought it'd be good some other naughty boy playing dangerous games 
> with interpreter internals not spend hours in debugger trying to reproduce 
> the crash.
> 
> > But tell me, what do you want the process to do instead of
> > terminating? Py_FatalError is used in situations where raising an
> > exception is impossible or would do more harm than good.
> 
> The need for this is only logging purposes. eg the process just terminates 
> on client machine, you have no logs, no clues(except a coredump), nightmare!.
> Some sort of log would be invaluable here.

Offering any hook for Py_FatalError may not even be enough, as some of
those errors are caused by insufficient memory.  What if a hook were
available, but it couldn't be called because there wasn't enough memory?

Of course there is the option of pre-allocating a few kilobytes, then
just before one calls the hook, freeing that memory so that the hook can
execute (assuming the hook is small enough).  I'm not sure if this is a
desireable general mechanic, but it may be sufficient for you.  If you
do figure out a logging mechanism that is almost guaranteed to execute
on FatalError, post it to sourceforge.


 - Josiah



More information about the Python-Dev mailing list