This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients dtcaciuc, kisielk, vstinner
Date 2011-06-27.21:44:32
SpamBayes Score 1.1828776e-07
Marked as misclassified No
Message-id <1309211073.04.0.987428518693.issue12423@psf.upfronthosting.co.za>
In-reply-to
Content
Extract of abort manual page:

"The  abort()  first  unblocks  the  SIGABRT signal, and then raises that signal for the calling process. This results in the abnormal termination of the process unless the SIGABRT signal is caught and the signal handler does not return (see longjmp(3))."

If you use a Python signal handler, you have to know that the signal is first handled in C. The Python callback is called "later". In your example, the C signal handler is called, but it *returns* and so the process is stopped.

Python exceptions are not implemented using longjmp() but using a global variable (storing the exception object) and functions return NULL, so I don't think that you can handle the abort() in Python.

> If instead of os.abort I call time.sleep(10)
> and then send a kill -ABRT from a shell, the exception
> is raised as expected.

Yes, this is different from abort() (read again abort() manual page, at least its Linux manpage).

--

abort() is really a corner case of signal handling. You have better to avoid abort() in your application, instead of trying to handle it. By the way, what do you want to do on abort()?

If you enable faulthandler, you get the Python traceback on abort().
History
Date User Action Args
2011-06-27 21:44:33vstinnersetrecipients: + vstinner, kisielk, dtcaciuc
2011-06-27 21:44:33vstinnersetmessageid: <1309211073.04.0.987428518693.issue12423@psf.upfronthosting.co.za>
2011-06-27 21:44:32vstinnerlinkissue12423 messages
2011-06-27 21:44:32vstinnercreate