[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Ilya Kulakov added the comment: Victor, it's very helpful to analyze which Python stack caused exceptions in native code on user's machines. -- ___ Python tracker

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: > Please ignore everything I said about AddVectoredContinueHandler. I finally > got a chance to test the code on Windows and the way it's called is not > suitable for faulthandler. Oh, good to know. Thank you for having tested that

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Ilya Kulakov added the comment: Please ignore everything I said about AddVectoredContinueHandler. I finally got a chance to test the code on Windows and the way it's called is not suitable for faulthandler. -- ___ Python

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Ilya Kulakov added the comment: Steve, the difficulty with SetUnhandledExceptionFilter is that it can replace filter installed by the user (e.g. one of loaded libraries). The information about AddVectoredContinueHandler is scarce, but according to what I found at [1]:

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: > I suspect the difference between that and AddVectorContinueHandler are > because of the weird prioritization of the two types of handler, and are > probably not significant enough to worry about here. Ok, thanks. I close the issue

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Steve Dower added the comment: SetUnhandledExceptionFilter could be a good option. I suspect the difference between that and AddVectorContinueHandler are because of the weird prioritization of the two types of handler, and are probably not significant enough to worry

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Ilya Kulakov added the comment: Another option is to use AddVectoredContinueHandler [1]. It seems to be called if both VEH and SEH failed to handle the error. 1: https://msdn.microsoft.com/en-us/library/windows/desktop/ms679273(v=vs.85).aspx --

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Ilya Kulakov added the comment: I think faulthandler should use both. E.g. in [1] you can read about an exception that can be handled by AddVectoredExceptionHandler but not SetUnhandledExceptionFilter. Perhaps implementation should use SetUnhandledExceptionFilter for

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: I backported the fix to Python 3.6. @Steve Dower: What do you think of using SetUnhandledExceptionFilter? -- versions: +Python 3.7 ___ Python tracker

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: New changeset 33217d22131ab1ffaa09a6944bae704f722f25a9 by Victor Stinner in branch '3.6': bpo-31701: faulthandler: ignore MSC and COM Windows exception (#3929) (#4416)

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: > May I ask why AddVectoredExceptionHandler is used instead of > SetUnhandledExceptionFilter? Honestly, I don't know well Windows API and so I'm not sure which one is the best.

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Change by STINNER Victor : -- pull_requests: +4365 ___ Python tracker ___ ___

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Ilya Kulakov added the comment: May I ask why AddVectoredExceptionHandler is used instead of SetUnhandledExceptionFilter? -- ___ Python tracker

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: > Does this change imply that no python-traceback-for-every-thread will be > printed upon both handled and unhandled C++ exception? Right if I understood correctly. The best is to test yourself ;-) --

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Ilya Kulakov added the comment: Victor, Does this change imply that no python-traceback-for-every-thread will be printed upon both handled and unhandled C++ exception? -- nosy: +Ilya.Kulakov ___ Python tracker

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: New changeset 6e3d6b5dc22cd06d8c4d44a38a8a3415e4bebb16 by Victor Stinner in branch 'master': bpo-31701: faulthandler: ignore MSC and COM Windows exception (#3929)

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Steve Dower added the comment: > Is it possible to be asked to be called as the last handler ... Unfortunately not, since the stack-based handlers always come after the vector handlers, and C++ handlers written using try/catch will always be stack-based. It may be

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: I abandon my intent to log all interesting errors: PR 3929 now always ignore all MSC and COM Windows exceptions. -- ___ Python tracker

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Change by STINNER Victor : -- pull_requests: +3904 ___ Python tracker ___ ___

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: I failed to build https://github.com/FynnBe/faulthandler-spam with a Python built myself. But I succeeded to recompile a Python extension (_overlapped) in C++ (I removed two functions which caused compilation error) and then added

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: I misunderstood how Windows works. UNIX signals handlers and Windows exception handlers are unrelated. Exception handlers are not called to handle a SIGSEGV signal (raised manually by the process itself, not raised by the Windows

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: I wrote the PR 3928 to call AddVectoredExceptionHandler(0, ...) rather than AddVectoredExceptionHandler(1, ...), but it doesn't work as expected. I tested "faulthandler.enable(); faulthandler._sigsegv()": a traceback is logged. But

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Change by STINNER Victor : -- keywords: +patch pull_requests: +3903 stage: -> patch review ___ Python tracker ___

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: > 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. (...) On the Internet, I

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: On the Internet, I also found the code 0xE0434F4D: 0xe000 + 'COM'. Should it be ignored as well? -- ___ Python tracker

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Steve Dower added the comment: Okay, just tested taking out the C++ handler and it goes straight to an error report. Not ideal, especially since the error is logged against "python.exe" and "ucrtbase.dll" (which is going to make my life harder when reviewing the

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Steve Dower added the comment: 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

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Steve Dower added the comment: We may just need to special case some well known exception codes for MSVC and the CLR, though if they're handled we may be dumping on the first chance and not the second chance handling. If I get a chance to dig into the docs and code

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Fynn Be added the comment: > Are you asking to *ignore* all 0xE06D7363 exceptions? Yes. This error is only indicating that an error was thrown, regardless if it was handled or not. Therefore it should not be treated as fatal, but it is by faulthandler: 'bool(0xE06D7363 &

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

STINNER Victor added the comment: The code of the current faulthandler exception handler lives at: https://github.com/python/cpython/blob/master/Modules/faulthandler.c#L364-L409 --

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Fynn Be added the comment: In the github repository there is 'build.bat' that creates the mscv 14 solution, builds it and runs the 'test.py'. Here is the output: ``` Windows fatal exception: code 0xe06d7363 Current thread 0x462c (most recent call first): File

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

Fynn Be added the comment: Here is a git repository with a test module and a test script: https://github.com/FynnBe/faulthandler-spam -- ___ Python tracker

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

New submission from Fynn Be : c++ extension compiled with MSVC 14 using python 3.6.2 on Windows 10 x64 Whenever a C++ exception is thrown in an extension the faulthandler dumps a traceback to it, even if it is caught. -- components: Windows messages: 303751 nosy: