[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