if an exception is thrown inside a try/catch, can i put a breakpoint there to get into debu mode before the program exits?
Tested here with a simple code, were I called a function that always throw. The breakpoints inside de catch block not ignored, and the debug mode started normally.
Anyway, qtCreator uses GDB for debugging (At least on my machine). You can find out more about how GDB handle exceptions debugging here http://www.caf.dk/cafonly/gnu/gdb/gdb_31.html
I don't see why not, this can certainly be done with the C/C++ IDE in Eclipse just by clicking in the margin where you want to break and running in "debug mode". In Eclipse, there is a run and a run in debug mode separation - I assume that's the case also in Qt Creator. Try it?
Related
I'm using Eclipse Mars and trying to debug a C++ file. I'm adding a breakpoint to a line, but after a few seconds I get the warning:
Breakpoint installation failed: Interrupt failed.
And the debugger doesn't stop at that point even though I know for sure that the code does reach the line with the breakpoint.
What can be done to solve this issue?
This messages indicates that the source file where you set the breakpoint does not belong to the actual binary you are debugging
The error message says: "interrupt failed". This does not seems to be a problem with matching binary with source file, it is rather a problem with GDB not being able to interrupt the process. My suggestion is to restart the debugger and set the breakpoint before the program actually starts.
I have this error sometimes when I debug a C++ multithreaded program in Eclipse.
Although I hadn't encountered such a problem with Eclipse, my suggestion is to look to Eclipse forum following these links:
https://www.eclipse.org/forums/index.php?t=tree&th=201329#page_top
https://bugs.eclipse.org/bugs/show_bug.cgi?id=331833
Make sure that "Skip All Breakpoints" is not enabled!
skip breakpoints button
I've had this warning on Eclipse TrueStudio Atollic. It didn't hamper at all my debugging. I rebuilt, checked breakpoint properties unsuccesfully. Then I remained in Eclipse ide, closed the project, reopened it and the warning had disappeared.
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":
I am remotely debugging a dll (C++, unmanaged) for Microsoft FSX (I do not know whether this matters). The dll is compiled as "Multi-threaded-dll", since it does not work as "Multi-threaded-dll debug". My dll currently just contains a DllStart and DllStop function, this is standard in FSX.
I general debugging works (it stops at my breakpoints), but somehow the debugger also stops in places where I did not place a breakpoint. First the issue came up in the "NO Source available" flavor. After checking
Suppress "No Source Available" pane in 2010 and
No Source available
the only solution working for me was to install the mentioned extension. Now I do not get the "No source" tab anymore, but debugger still stops somewhere outside my code. I have cleaned all breakpoints as recommended in " Debugger stops when there is no breakpoint VS2010 ".
bglmanx.dll is another dll, also started by FSX. I was thinking, OK, maybe there is some ambiguity about the symbols and have renamed my functions to DllStartFSXM and DllStopFSXM (and hence being unique). No improvement.
Any ideas, hints?
It could be caused by having __asm int 3 or a DebugBreak in the other code?
Perhaps there is some way of disabling these commands or reimplmenting the DebugBreak function?
I left a program running last night, it worked fine for about 5 hours and then one of its built-in self-diagnostic tests detected a problem and brought up a dialog box telling me the issue. The program was built with debug information (/Zi). Is it possible to somehow get the debugger started so I can examine the value of some variables within the program? Or is it too late?
You can attach the debugger to the running process:
Debug > Attach to Process...
Just open up the program's solution first.
Assuming you've still got the error dialog on the screen you can break into the program and work back up the call stack examining variables etc.
For the future crashes ... if you have windbg or Visual Studio Professional, you can debug crash dumps, even when program isn't running. It is quite useful sometimes. See "MiniDumpWriteDump" on MSDN for more info.
Other than that it is "Attach to process".
Professional edition of Visual Studio have Just-in-Time debugger, that will kick in as soon as anything crashes, even if MSVC wasn't running. It will also locate source code (if debug info and source code are available) and open/create solution for you.
There is an option in the Debug menu to attach the debugger to a running process, IIRC.
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."