Here's the scenario. I'm debugging my own app (C/C++) which is using some library developed by another team in the company. An assertion fails when my code generates some edge case. Its a pain because the assertion is not formulated correctly so the library function is working OK but I get all these interruptions where I just have to continue (lots as its in a loop) so I can get to the stuff I'm actually interested in. I have to use the debug version of the library when debugging for other reasons. The other team wont fix this till next release (hey, it works on our machine).
Can I tell the debugger to ignore the breakpoints asserted by this section of code (i.e. can it auto-continue for me).
If the code is triggering breakpoints on its own (by __debugbreak or int 3), you cannot use conditional breakpoints, as the breakpoints are not know to Visual Studio at all. However, you may be able to disable any such breakpoints you are not interested in by modifying the code from the debugger. Probably not what you want, because you need to repeat this in each debugging session, however still may be better than nothing. For more information read How to disable a programmatical breakpoint / assert?.
There's no good way to automatically ignore ASSERT() failures in a debug library. If that's the one you have to use, you're just going to have to convince the other team that this needs fixed now, or if you have the source for this library, you could fix or remove the assertions yourself just to get your work done in the meantime.
You can add an exception handler around the call(s) to the library, catch the EXCEPTION_BREAKPOINT exception and do nothing.
Example 2 in the following link seems to be what you want to do:
http://msdn.microsoft.com/en-us/library/ms681409(VS.85).aspx
You can use conditional breakpoints. Some links:
http://support.microsoft.com/kb/308469
http://dotnettipoftheday.org/tips/conditional_breakpoint.aspx
Related
I'd like to extend my application with a kind of logging, where one can choose to log to a file and/or to log to the "Visual Studio" "output" window.
For the latter, it seems that the function OutputDebugString() is doing the trick, but only for "Debug" builds, and I'd wish to have this also for "Release" builds, so I came up with the idea of using tracepoints (at least, I think that tracepoints are also writing to the "output" window for "release" builds), but here I have a rather frustrating problem:
Tracepoints are a special kind of breakpoints and seem to be written to *.suo files, being present in <project directory>\.vs\<project name>\v15 directory (see Where are Visual Studio breakpoints saved?., thank you, Max).
My idea was to write a postbuild event, adding a tracepoint to every line in the *.suo file where a log() operation was called.
This, however, is not possible, for the simple reason that the *.suo files are binary :-(
Does anybody know of another way to add tracepoints to an application at build-time or how to write (with a "Debug"/"Release" switch) to the "output" window of Visual Studio?
Thanks in advance
OutputDebugString() should work in Release builds - if there is anything to consume the output (such as WinDbg.) Debugging Tools for Windows (WinDbg, KD, CDB, NTSD)
As to why it's not - probably want to look into that, as it's possible your application isn't building quite the way you expect otherwise.
As I understand it, Tracepoints only work in a debugger (Debug or Release) - but the way I believe this works is, the debugger will, on application load/startup, (or during a run) actually replace instructions with a BRK and when the application triggers the break, the debugger catches it, substitutesthe original instruction back in, before performing whatever task it should (whether that be pause, increment a counter, etc.) - but I think Tracepoints will only work with an attached debugger, as otherwise there's nothing to perform the replace, catch and substitute operations, and the code runs uninterrupted.
However, if I read your intentions correctly, you might actually want to use something like Event Tracing* instead. This should output what you want to see to a standard windows log file, will work in debug or release, inside or outside of a debugger. However it won't output to the VS output window. For that, OutputDebugString() should the be correct operation.
*Disclaimer - not used them myself, as we use VS output and WinDbg for now - but it looks like a better way for deployed applications, going forwards.
We have a problem for which I am looking for a direction. We have an old MFC based application, and due to various reasons, the application is crashing sometimes intermittently in some weird scenarios. And even the customers who are using our application and getting these crashes are finding difficulty in identifying the pattern of crash. So, I had a thought that, if we can have a mechanism by which we can generate a log whenever the application crashes. Like for example, the call stack or any other information in that log. I know,, we can use the crash dump in this case, but then I feel like having a log is a better option. So any help or information in this regard would be really helpful.
Thank you.
You can find a good implementation of crash reporter in the link here.
When you compile your release build, make sure that both DEBUG and /MAP are enabled. Store your binaries together with your .map files and let your customer run this version until a crash is produced. In the Event Viewer you will then find a crash log with a crash offset. Then debug step into your code (F10) and use the crash offset together with some nifty tricks and tricks to jump (set the EIP register to... well, you have to google this a bit) to the location where the crash occurred. You should now be able to find the error!
I have a corruption memory heap with my application. I would like to use Application Verifier in order to find the bug.
I have some difficulties to find a tutorial on how use Application Verifier.
One of the first question I'm wondering is should I use my application in DEBUG or RELEASE mode ?
Thanks
Typically, in debug mode with a debugger attached will be your first stop. This provides full run-time checks, more validation, and more accurate information on what is going wrong. Application Verifier can also signal the debugger to break and will output error information, so having a debugger attached is very useful.
After that, as Simon Richter noted, you'll want to run most of it again in release. Release builds typically don't have the same checks and don't watch for errors, so things are very likely to surface that weren't an issue in the debug build. There is some use for a sort of manual-debug or hybrid build, where you perform some of the checks and logging to make sure things don't go too far afield.
To use Application Verifier, you really just need to start it, add an application and enable to desired tests. When you run, it will create a log and send messages/breaks to a debugger if one is around.
With the necessary experience in debugging, "Both" would be the right answer, as the differences between Debug and Release builds also give good hints about the source of the problem.
If you do not want to dive that deep into the inner workings of the compiler, then use the Debug version if the error appears there reliably.
usually debug versions run the application verifier to find the bugs in the app.
I am debugging an Iphone program with the simulator in xCode and I have one last issue to resolve but I need help resolving it for the following reason: when it happens the program goes into debugging mode but no errors appear (no BAD ACCESS appears) and it does not show where the code fails. Putting some variables as global helps me to see their values to start pin pointing where the bug is but before I go into this fully I would like to know what techniques/tools you guys use to debug these situations.
If it helps Im debugging the following: I merged some code into the SpeakHere demo. The code was added in the C++ modules of the program (AQRecorder.h and .mm). I seem to have pinpointed the problem code in a function I wrote.
My favourite is always to add debugging code and log it to a file. This allows me so report any and all information I need to resolve the issue if the debugger is not working properly.
I normally control the debugging code by use of a flag which I can manipulate at run time or by the command line.
If the error is (and it probably is) a memory management issue, printing log entries is really not going to help.
I would reccomend learning how to use Instruments, and use its tools to track down the memory leak when it occurs rather than waiting until the application crashes later on.
When I hit a normal assert statement while debugging with Visual Studio I get the option to break into the debugger so I can see the entire stack trace and the local variables, not just the assert message.
Is it possible to do this with Qt Creator+mingw32 and Q_ASSERT/Q_ASSERT_X?
It's possible. Somehow the feature stopped working for me, but basically what you want is to stop on qFatal().
To ensure this happens, in qt Creator go to Tools -> Options -> Debugger -> GDB and select
"Stop when a qFatal is issued"
You can install a handler for the messages/warnings that Qt emits, and do your own processing of them. See the documentation for qInstallMsgHandler and the example they give there. It should be easy to insert a break in a custom message handler (or indeed, just assert on your own at that point). The one small drawback is that you'll be a bit further on down the stack than where the error actually occurred, but it is a simple matter to just step up the stack until you are at the proper frame.
It's possible. I have coded a BreakInDebugger function by hand and an assert macro that calls the function.
e.g: #define MyAssert(X) (BreakInDebugger();Q_ASSERT(X))