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 steve.dower
Recipients Fynn Be, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2017-10-07.16:22:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507393330.42.0.213398074469.issue31701@psf.upfronthosting.co.za>
In-reply-to
Content
Haven't had a chance to test this, but I suspect our change should depend on what happens when a C++ exception is actually unhandled.

In this case, the following sequence has occurred:
* exception is raised
* debug event is raised (if a debugger is attached)
* stack-based handlers get first-chance to ignore the exception
 * there is a stack-based handler that says "let it be raised" and the search stops
* vector-based handlers are called
* stack unwind begins, and when the handler is reached it allows execution to continue

Unfortunately, I don't think there's going to be any difference between the unhandled and handled cases at the point where our handler exists - at worst, the OS is going to say that it is "handled" and its handler will kill the process. The first chance lookup is actually there to continue execution and ignore the exception (possibly after fixing an argument or allocating a new page, etc.).

So I think our choices are:
* report no C++/CLR exceptions via faulthandler
* report all C++/CLR exceptions via faulthandler (current behaviour)

I'm inclined towards changing to the first option. The runtime is going to dump a more useful message than us if the exception makes it that far, and a C++ exception can never be caused by CPython itself.
History
Date User Action Args
2017-10-07 16:22:10steve.dowersetrecipients: + steve.dower, paul.moore, vstinner, tim.golden, zach.ware, Fynn Be
2017-10-07 16:22:10steve.dowersetmessageid: <1507393330.42.0.213398074469.issue31701@psf.upfronthosting.co.za>
2017-10-07 16:22:10steve.dowerlinkissue31701 messages
2017-10-07 16:22:09steve.dowercreate