I have a Qt application that I compile in release configuration, run, and then perform operation X in the program. Everything runs fine.
I then compile it in debug configuration, run without debugging (so CTRL+F5), perform operation X in the program. Everything still runs dandy fine.
But when I try to run the debug configuration with debugging (so just F5) and then perform operation X, Visual Studio breaks in with a message that an exception has been thrown... in a completely unrelated part of the program (code being executed is far from the site where VS breaks, in the QHash template)... and then VS hangs and I have to kill it with the Task Manager. I can repeat this ad infinitum, and it always freaks out the same way.
Boost::exception is used for the exceptions. VS is 2008, SP1. Qt is 4.6.2, using the precompiled VS binaries from the Qt site.
Does anyone have a clue what is going on?
Visual Studio has a feature called "first chance exception handling" where, when running attached to the debugger, you can have the debugger break when exceptions of certain types are thrown.
You can change these settings by going to Debug -> Exceptions (Ctrl+Alt+E) and (un)checking the appropriate checkboxes.
When it breaks you should get a message in the Output window indicating what exception was thrown.
If you have _HAS_ITERATOR_DEBUGGING enabled (it is enabled by default in debug builds), it can cause a lot of iterator errors to throw exceptions instead of performing operations that would cause access violations. That's the only thing I can think of off the top of my head that would cause an exception to occur "randomly."
Related
I am wanting to use Visual Studio's Graphics Diagnostics to debug some shader code, but when I try to "Start Diagnostics", I get an immediate access violation in dxgi.dll. This access violation appears to occur before my program's main function is even entered. I tried adding a Sleep just inside my WinMain function so I could attach a separate debugger, but this code was never hit. I opened one of the DirectX SDK sample programs with the same installation of VS2013 and the Graphics Diagnostics worked fine. I also tried using Graphics Diagnostics on my program on two separate PCs and they both threw the same access violation.
I suspect maybe it has something to do with my project configuration? It seems to be failing to establish a connection between the Graphics Diagnostics debugger and my program before the entry point of my program is called.
Any ideas are much appreciated!
My code is crashing in the Release configuration but not the Debug configuration. It's only doing this as I exit the program as the very last line 'return(0);' executes. I'm working in the Visual Studio development environment and when it crashes, VS studio offers me the option to 'Debug' the code. When I select that, it leads to an error dialog that pops up saying:
Unhandled exception at 0x00007FF851A0512D (msvcp120d.dll) in myapp.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
When I select to 'break' when this exception occurs, it highlights the following function in the xstring file:
void _Free_proxy()
{ // destroy proxy
typename _Alloc::template rebind<_Container_proxy>::other
_Alproxy;
this->_Orphan_all();
_Alproxy.destroy(this->_Myproxy);
_Alproxy.deallocate(this->_Myproxy, 1);
this->_Myproxy = 0;
}
And, especially, the line '_Alproxy.destroy(this->_Myproxy);' is highlighted as the culprit.
I thought the issue might be that my 'release' code is somehow linking to the 'debug' msvcp120d.dll library since that's highlighted in the 1st dialog that pops up - but that may be just because I start using the VS debugger to ID this problem. But even if that is the problem, I'm uncertain how to tell VS to compile with msvcp120.dll for the Release configuration and msvcp120d.dll for the Debug configuration.
(For the record, I'm generating all my code using the 'Multi-threaded DLL (/MD)' flag in the Release configuration and the 'Multi-threaded Debug DLL (/MDd)' in the Debug configuration)
The kicker is that when the Release version crashes, the process enters a 'suspended' state and I'm unable to fully kill it via task manager. And then I can't even recompile a new Release version without restarting my computer!
I don't know how to isolate this problem. Can anyone advise me on how I might fix this?
Update
The code for this project is quite large - so distilling it to a minimal version that exhibits the same behavior, while usually a valid way to track a bug, would be a pretty big task. I was hoping that there was some method to log the processes and figure out which one is calling msvcp120d.dll #Niall, I generated the dependency graph and it is huge. Without giving away anything proprietary, attached is a global view of the graph.
Dependency graph of entire solution
Is there any tool to track which is calling msvcp120d.dll?
#Niall Thank you! The software at Dependencywalker.com was fantastic. I was able to use it to determine the library causing the problem and track down the error. It turns out that I had previously (months ago, dumbly) set a system path to the debug version of that library. So even though my project was properly directed to link to the release version of the library, at runtime, my executable was linking to the debug version of the *.dll file!
I deleted the path variable and now make sure a copy of the proper *.dll file is in my Release or Debug directory. Then it all runs and shuts down fine.
Thanks to all who provided assistance.
There are a number of errors going on here but I'm sure they are all linked, so first off I'm getting Access violation reading location exceptions at locations (generally near 0x00000000)
but I only get these exceptions in release and not in debug, even if i setup debugging to do so. Also I found where the error happens but when I step over that it goes in to a complete unrelated function that is not called in the line or in any of the functions in that line of code. But when similar code is called it still goes to this unrelated function but doesn't fail. This all only happens in release versions. I know which piece of code is causing the error as if I comment it out its all fine. Also in the watch window in release all the numbers are wrong most of the time, which has never been a problem but it could help also a added some code to it to output the values of variables to a file and the variables are all fine, the pointers are sensible, but when the exception happens it always says their 0x00000020 but when I look at the log they are fine. This is in 32 bit , but on 64 bit windows 7 in c++. Please any help would be good!
Visual Studio's debugger will cause the program to use a debug heap that can hide uninitialized memory if you use the option "Start with Debugging" to start your program, in release or debug. You can try to run your program built in the Debug configuration without the debugger attached, and then use the Attach to Process... option in the debug menu to attach to your executable.
If this doesn't help, I recommend using windbg to debug your program. For help getting started with windbg, take a look at the answers on this question.
Once windbg is configured and symbol paths are set up, you can use the "!analyze -v" option once the program crashes to get a lot of information about the crash automatically.
I am Debugging some BOOST unit tests in QtCreator and it sadly happened that they crash with an exception. How can I make QtCreator automagically break if any exception is raised? In Visual Studio there is a tick box for this one, is it also available in QtCreator?
In my case, BOOST catches the exception, so the program doesn't technically crash. However, the reported message is not really helpful.
I tried the same in KDevelop previuosly, hence I am asking separate questions about both of these IDEs.
Open Debug mode (Ctrl+F4 or just 4th mode on right bar).
Open context menu in breakpoints list at right bottom:
Select "Add Breakpoint" and set the breakpoint type to "Break when C++ exception is thrown":
Is there any benefit in starting a debug build without debugging (as opposed to a release build without debugging)? And what do I miss when I debug a release build (as opposed to debugging a debug build)?
Biggest advantages of debug builds (outside of the IDE):
Assertions are enabled, as is other diagnostic code you may have compiled within debug-dependent prepocessor sections.
Stack traces and variable watches are working properly, so you can have beta testers send you a crash dump and debug that in your IDE later.
Biggest disadvantages:
Slow execution, higher memory consumption, bigger file size.
Some bugs are not evident unless you compile everything with full optimization. That's because memory allocation is working differently in release builds.
Many companies distribute debug builds to alpha and beta testers and switch to release builds later.
To add to Adrians answer and as a general point when talking about debug vs. release builds:
Here are some factors that influence your builds:
You link against either the debug or the release runtime libs (/MD vs. /MDd)
NDEBUG (release mode) or _DEBUG (debug mode) is #defined
_SECURE_SCL (or some equivalent) is defined (or not)
Compiler optimizations are enabled (to some degree)
A "debug build" normally comprises _DEBUG, _SECURE_SCL=1, /MDd and all compiler optimizations disabled. This results in the "safest", "most-checked" execution mode, but also should be the slowest version you can get for your executable. The speed and safeness factors should be completely independent of whether you run your program under a debuger or not! -- The debug build gives you a maximum safety and error catching net, completely independent of whether the program is attached to a debugger.
Next comes a non-optimized release build: That is, you have all the release mode settings (NDEBUG, _SECURE_SCL=0, etc.), but you disable all compiler optimizations. This is good for testing, since performance won't be bogged down too much and you can debug this allright. Again, the usefulness of this is independent of whether you run your program under a debugger.
Finally come full optimizations. (/Ox + full inlining + possibly whole prg optimization): While this is what you would like to ship for performance reasons, chances are that you do not have enough people in your company that are actually able to debug this. That is, given a crash dump, someone most likely needs some amount of asm knowledge and what a compiler outputs to make some sense of the crash dump (or even some random breakpoint, when actually running under the debugger). Again, the pros/cons for full opt are independent of starting/running the prg under a debugger.
Starting a debug build without debugging can give you for example the following benefit: if a contrainer is indexed with an invalid index you'll get an assertion failed, in release mode you'll get undefined behavior. That's one thought. What you miss when debugging in release mode is that there is no correspondence between source lines and assembly code any more because the optimizer has run. So it's far more difficult to debug in release mode
I'll offer a recent experience that I can't explain -- sometimes when I run my application, I get unhandled exceptions when running in the IDE. The problem is, I know my exception is getting handled, and I also know that I'm not breaking on thrown exceptions (via CTRL-D, E). If I hit F5 several times, my error handler eventually catches the exception and deals with it properly.
The reason for this has eluded me for several weeks, so when I don't want the execution to get interrupted, I run outside of the IDE and simply attach to the process later if I need to.
If you really need to see the Debug output while running outside of the IDE and you're not using something like log4net to capture everything, you can use DebugView instead.