-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
catch triggers infinite SEH exceptions in some cases #810
Comments
I'll take a look soon, I think this is an issue we solved on Linux and I forgot about changing the logic for Windows SEH as well -- on Linux, Catch deregisters its handler before attempting anything else, so if the handling triggers another signal, we do not enter into recursion. Also note that Catch does specifically NOT attempt to shutdown gracefully. It uses the vectored exception to fail the current section, print out what roughly happened and then pass it upward, which usually means passing to the default handlers. |
I ported the same logic the Linux signal handler uses to Windows -- Catch now deregisters its handler before attempting to do anything else. Can you check if the attached single file header works as expected? |
Thanks for the quick answer. I tested your version, it does not fix the bug, here is a stack with 3 exceptions stacked:
Moreover, there is a regression as the following lines do not compile anymore for me:
As for your policy about handling crashes in Catch, wouldn't it be better if Catch avoided to trigger a second crash so that it could at least close all xml elements and exit the application? I remember that in some previous version of catch, the reportFatal function used to call exit(). It seems that it now just returns and the code just crashes again in a loop. Since C++ is very prone to crashes, I think there is a real need for correct crash handling (at least we have a need for it). |
The nullptr regression is the result @philsquared inadvertently merging half-prepared changes to master, not reverting all of them and should not be present in v1.7.1. As to the last part, there was a request for Catch not to swallow crashes, so it does not prevent creating dumps, attaching debugger, etc. on crash, so we don't want to call I'll see about making the handling inside Catch saner though. |
Finally got back around to this and I think I found the underlying issue -- the attached version of single-include should not trigger recursive SEH exceptions and/or signals -- but did not have time to fix it properly, so the output is broken. Can you test this again? |
Description
On windows, when a crash occur, catch may make the program crash a second time instead of gracefully handling the crash and quitting. This goes on infinitely, until the stack overflows I think.
Steps to reproduce
Extra information
On my machine, this bug happens only when compiled in RelWithDebInfo, not in Debug. Also, I am using the JUnit reporter and writing the output to a file, but I'm not sure this matters.
It seems that the comparison doesn't crash, somehow, but Catch tries to expand the expression. When it tries to do that, the program crashes and handleVectoredException is called, which in turn tries to print the capture exception and makes another exception trigger again.
Here is the full stack trace. The first exception is at the ntdll.dll marker, and the second is at the top.
Catch should somehow not try to expand expressions when it is handling a fatal exception.
The text was updated successfully, but these errors were encountered: