RetroSearch Browse

Mon Dec 20 01:19:35 CET 2010 · https://mail.python.org/pipermail/python-dev/2010-December/106905.html

Le lundi 20 décembre 2010 à 00:02 +0100, Victor Stinner a écrit :
> Another possible approach is to restore the previous handler in the
> fault handler, and don't call abort(). The fault should occur again, and
> so the previous signal handler will be called.

I implemented this simple approach in the version 10 of my patch: the
previous signal handler is called.
http://bugs.python.org/issue8863#msg124373

On my Debian Sid, the libc fatal error message is written as expected
(eg. "Segmentation fault") and the exit code is different for each fault
(eg. 132 for SIGILL). So we keep the existing behaviour, the new Python
fault handler just write more information if a fault occurs.

I suppose that it is compatible with the grsecurity thing and Apport,
but I didn't tried. Can someone test it?

I prefer to restore the previous signal handler than restoring the
*default* signal handler.

> I choosed to not call the previous handler to keep the patch simple.

It's cool: restoring the signal approach keeps the code simple, and it
looks like it works :-)

Victor

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-December/106905.html below:

[Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable