I am writing a new UT in my code (C++, VS10).
Apparently there is an error somewhere in the test. I see the following error in the compilation console
unknown location(0): fatal error in "Test1": breakpoint encountered
I want to debug the test to see what is wrong, but I can't, since this test failure cases the compilation to fail, and prevents me from running the code inside VS debugger.
I guess I can copy my code to the main() function, but this is problematic since the test requires many includes that are absent from that part.
Is there any other option?
Use DebugBreak inside Test1. It will crash and then you can attach the application to debugger. However, if debug information is not generated, you have to debug through assembly code.
Simple usage of DebugBreak
DebugBreak(); //Include Windows.h for it.
Related
I'm trying to compile a simple GTk app, but when I compile, build fail due to warning in GTK source…
Compile log:
Compile
[Ada] main.adb
gdk-display.ads:361:80: (style) this line is too long
gdk-event.ads:290:80: (style) this line is too long
…
gprbuild: *** compilation phase failed
Anybody have solution ?
Thanks
You could:
Choose not to treat warnings as errors.
Fix the issues the compiler complains about.
You can adjust compiler flags on a per-file basis in project files, so you don't have to drop your zero-warnings policy for the rest of the project, just because you do it for selected files in GtkAda.
I have a __forceinline function that cannot be inlined when compiled as CLI (probably due to the specific restrictions to inlining that apply with .NET).
In debug, it is a warning and does not prevent me from building. But in release, it comes up as an error:
error C4714: function '...' marked as __forceinline not inlined
In the project configuration, Treat Warnings As Errors is set to No (/WX-), Treat Specific Warnings As Errors is empty (no value and no inherited value) and there is no /We option in the Command Line of the C/C++ section.
Thus, I don't understand why this warning comes up as an error.
And as it is an error it prevents me from building the project in release.
Do you have any clue on why this comes up as an error?
Any idea of how I could get rid of it, considering I cannot change the function nor its use (it comes from a library I'm using and I'd like not to alter)?
Thank you very much!
Asking this question preemtively because there is not much to be found about this error code. It is rather trivial to solve, but cost me a lot of time to diagnose because no proper error message is given.
So what happened?
I added templated functions to my project
Now when the project compiles, A message pops up saying that CL.exe had a problem and needs to be closed
Visual Studio aborting the compilation with error MSB6006: "CL.exe" exited with code 1
The problem were syntax errors in my template functions. Who could have guessed that.
However, it was hard to find out, because these did not get reported. See my answer for how to determine which functions are defective.
The templated functions were in a .cpp included in the header, however, defining them completely in the header did not make any difference.
// foo.h
template <typename T>
void foo();
...
#include "foo.cpp"
// foo.cpp
template <typename T>
void foo()
{
...
}
First you need to compile all .cpp files that include the templated functions seperately (select one in the project explorer, right click and "compile").
For me, the first hint was that some of them compiled, while for others cl.exe crashed.
The next step was to create a bogus.cpp file with just one function, where one by one I added calls to every templated function I created. After adding one: recompile. This went well until I got to the defective one, now the bogus.cppalso crashed cl.exe. Jackpot.
The last job was fixing the syntax error, which is annoying without error messages, but once this is done, bogus.cpp will compile again. Return to adding more function calls there until you have everything covered.
Hope I could help.
What fixed it for me was that I had two instances of Visual Studio running, and while one of them was in the middle of a debugging session, I tried to compile the other instance. Stopping the debugging session fixed this error for me.
Encountered the same issue with simple form and VS2019. This does not seem to be related necessarily to a code issue, but potentially with VS itself.
Took fresh checkout of code, built OK.
Added new tab to existing form, CL.exe exited with code 1 error.
Reverted code and added changes until error presented then could not get error to clear, event after clearing build output directories.
Completely reverted build - CL.exe exited with code 1 error.
Performed update of VS to 16.4.0 and restart PC - project builds OK.
I have several simple macros that exist in some files across a large project that includes a #error. They all follow this structure, more or less:
#ifdef COMPFAIL
#pragma message "Compilation Has Failed"
#error
#endif
I want to set the project up so that, if COMPFAIL is defined, the #pragma within each file occurs with compilation ultimately failing. I now understand that when #error is called, it halts compilation on the spot, not attempting to compile any of the other files defined in my Makefile and preventing all further #pragma calls from occurring. Is there a way to force the compiler to finish preprocessing across all files before failing?
A very simple test:
#error foo
#error bar
Compiling this file with gcc produces the following results:
t.c:2:2: error: #error foo
#error foo
t.c:3:2: error: #error bar
#error bar
It's obvious that #error does not completely stop the compilation of the file. If it were, only the first error would've been reported, and the compilation would've stopped. But, after the #error, the compiler keeps going, and continues to preprocess, and compile, the rest of the code. However, it's pointless, since the compiler will not produce an object file, once an error occured, so it's not clear to me what benefit you expect to gain from continuing to preprocess this file.
Now, as far as any other files that gets compiled via your makefile, that's completely unrelated to what any pragma or directive does, insofar as compiling or preprocessing the rest of the file. Once a command executed by make terminates with a non-zero exit code, make stops executing any more commands. To change that, use the -k option, as it's already been mentioned.
Note, that the -k option has no direct relevance on whether #error does or does not abort the immediate compile at hand. Either way, the compile stops with a non-zero exit code, and that's the driving factor, here.
I used to work with the Release version of VS2010 and suddenly, when switching to the Debug version, I get a breakpoint error message and it's redirected to the file dbgrptt which exists at C:\Program Files\Microsoft Visual Studio 10.0\VC\crt\src\dbgrptt.c
The displayed error message is:
ex.exe has triggered a breakpoint
This is where is redirects after showing the error message.
_CRTIMP void _cdecl _CrtDbgBreak(
void
)
{
__debugbreak();
}
How can I get rid of it?
The debug version of the CRT detected that something went wrong. The debug version sacrifices runtime speed in order to do more expensive checking so that it can detect such situations. They are typically caused by a bug in your code. In other words, you an error that happened not to manifest in the release build - so far.
How do you get rid of it? Fix the error. Run your program under the debugger, and when you reach the error, check the call stack. Go up the call stack until you find out what happened. Chances are, you are doing something like using a dangling reference/pointer, or an invalidated iterator, or you access something out of bounds.
From Microsoft Docs:
Assertion statements compile only if _DEBUG is defined. Otherwise, the
compiler treats assertions as null statements. Therefore, assertion
statements impose no overhead or performance cost in your final
Release program, and allow you to avoid using #ifdef directives.