What settings must I set in Debug -> Exceptions so that my catch statement will catch an exception arising from a boost header file? I have try-catch statements but when an exception occurs it just highlights the line of the exception and asks whether I wish to break or continue.
In Debug->exceptions I have ticked both boxes for "C++"
(C++ user unhandled is ticked, but grayed-out)
Related
I'm debugging a CMake target in Visual Studio 2019 for a project which is managed by CMake and built using MinGW.
However, when an assertion fails the debugger simply quits without giving me a call stack or letting me inspect the current state of the program. (Normal breakpoints do suspend execution as expected.)
I've enabled Break When Thrown for all C++ Exceptions in Debug > Windows > Exception Settings, but to no avail.
How can I make Visual Studio break execution when an assertion fails?
If your project is a "Console" application rather than a "Windows" application and you have used <assert.h> then according to the documentation:
The destination of the diagnostic message depends on the type of
application that called the routine. Console applications receive the
message through stderr. In a Windows-based application, assert calls
the Windows MessageBox function to create a message box to display the
message with three buttons: Abort, Retry, and Ignore
So a possible solution is to temporarily build your program as a "Windows" app by adding the WIN32 option to your executable definition:
add_executable(<name> WIN32 [source1] [source2 ...])
It is possible that the NDEBUG macro is enabled in your project and that stops VS from breaking on assertion failure.
From cppreference
If NDEBUG is defined as a macro name at the point in the source code
where is included, then assert does nothing.
If NDEBUG is not defined, then assert checks if its argument (which
must have scalar type) compares equal to zero. If it does, assert
outputs implementation-specific diagnostic information on the standard
error output and calls std::abort. The diagnostic information is
required to include the text of expression, as well as the values of
the standard macros FILE, LINE, and the standard variable
func (since C++11).
I'm using the Visual Studio /EHsc exception handling mode in my project. This means catch(...) won't catch structured exceptions. I've got a public header that does a catch(...) that can be included by consumer projects.
I'm concerned that a project consuming my header may have a different exception handling mode that will make my header misbehave.
Is there a way of static_asserting or #pragma error'ing or otherwise failing the build if the exception handling mode isn't as needed?
See: https://msdn.microsoft.com/en-us/library/1deeycx5.aspx
From https://msdn.microsoft.com/en-us/library/b0084kay.aspx
_CPPUNWIND Defined as 1 if one or more of the /GX (Enable Exception Handling), /clr (Common Language Runtime Compilation), or /EH
(Exception Handling Model) compiler options are set. Otherwise,
undefined.
It's not perfect, but it gives you a fighting chance to get them the same
I am a Windows developer with some knowledge of C++ EH and SEH implementation in VC++ but new to MinGW. I have built an open source application on MinGW where a dll throws a C++ exception and a client .exe catches it with two catch clauses. One catch clause is "catch (std::exception &e)" and the subsequent one is "catch(...)".
My application terminates with a call to abort despite the latter catch handler.
From searching the web, I understand that gcc exception handling uses pointer comparison to determine whether that type of a thrown exception matches a catch clause. Which can cause problems if the RTTI type descriptor instance used in the throwing and the catching modules differ. In VC++ a catch handler with ellipsis type ("catch (...)") does not do any type matching. However, for my mingw application the ellipsis catch is not determined as handling the thrown exception. I tried to set a breakpoint on ___gxx_personality_v0 to debug this but gdb says that symbol is undefined even though "nm executable.exe" built with debugging shows the symbol as defined.
Any ideas about how "catch (...)" is handled by the personality routine ? Any pointers on how to debug and/or fix this would be appreciated. I really would like the app to terminate cleanly without a popup saying "The application has requested to be terminated in an unusual way".
Thanks for any help,
--Patrick
Update: I found the solution in another post here about the same issue: Exceptions are not caught in GCC program . It turns out that both the dll and the executable were built with "-static-libgcc". Changing that to "-shared-libgcc" fixed the issue.
The quote from the gcc manual from the above post:
... if a library or main executable is supposed to throw or catch exceptions, you must link it using the G++ or GCJ driver, as appropriate for the languages used in the program, or using the option -shared-libgcc, such that it is linked with the shared libgcc.
I'm getting exceptions when I include afxmt.h, I know it's not my code because I tested it with an empty project that only included that file.
It first throws a first-chance exception (mfc100ud.dll) and then it jumps to thrdcore.cpp AfxInitThread() and then goes to tidtable.c
Is there some project settings that I'm missing or some other stuff? I'm using VC++ 2010 Professional.
First-chance exception at 0x00b794ea (mfc100ud.dll) in Quick_Test.exe: 0xC0000005: Access violation reading location 0x00000000.
Unhandled exception at 0x77b815de in Quick_Test.exe: 0xC0000005: Access violation reading location 0x00000000.
Stops at thrdcore.cpp line 405 and then in tidtable.c line 500.
EDIT:
Just tested this with a project that has precompiled headers and it worked. How would I make it work on my other projects, that were originally empty? Or should I just use a project with precompiled headers?
One reason could be that you are using release and trying to access the debug dll. Debug dlls usually ends with a "d" letter
Documentation states that "You must use /EHa when using _set_se_translator.".
My question is: should /EHa be used for all files in project/ all files in project that catch exceptions or just in the file that calls _set_se_translator ?
You need it not just for functions that catch exceptions, but also functions that throw and propagate them. The actual call to _set_se_translator itself probably doesn't need to be compiled with /Eha, but why be inconsistent?
After checking I must disagree with what has been said before about all instances needed to be compiled with /EHa. I made a small program with:
crashing code
__declspec(dllexport) void crashMe() { *((int*)0)=0; }
in a DLL compiled without any exception handling at all
calling code elsewhere in a try/catch
Then
Unless the calling code is compiled with /EHa the program will crash
Without _set_se_translator the exception can only be caught in catch(...)