I have been working on a single thread C++ program using visual studio. I have been running the "debug" version and normally If I come across some kind of crash the debugger helpfully points me to the bad line in my code. Sometimes the crash happens within a C++ library function in which case I look over to the "Call Stack" window and can quickly spot the last call from my code which called the library function.
But now I am struggling with a "Exception thrown" problem where the crash occurs in "strcat.asm", but the Call Stack does not display any code I recognise. In the call stack window I can see things like "ntdll.dll!__RtlUserThreadstart#8() - whatever that means!
How can I find what part of my code led to this crash?
UPDATE: after much pain, I finally found that the bug was essentially
value[idx] = a;
where idx had taken on the value -1. This, no doubt, had corrupted the stack.
I'm writing a 3rd party plug-in for a closed-source application. I'm running into a problem with the XCode debugger.
I'd like to use the debugger to step through the code of the plug-in I'm writing. To do this, I've set a breakpoint in my code, I've launched the host app, and then I've attached the XCode debugger to the host app's process. My problem is that, rather than stopping at my breakpoint, the debugger stops instead at an exception thrown by another part of the program. (Specifically, this: Thread 2: EXC_ARITHMETIC (code=EXC_i386_DIV, subcode=0x0))
This exception is thrown so often that it effectively makes it impossible to step through the code I'm actually interested in.
I can't catch and handle this exception, because I don't have the source code for the part of the app that throws it.
In this situation, can anyone suggest how I might be able to debug my code? Is there any way to tell the XCode debugger to simply "ignore" this particular EXC_ARITHMETIC exception, and, instead, to stop only on the breakpoints that I've explicitly set?
UPDATE
#user1118321 suggested turning off exception breakpoints using the breakpoints pane. I've tried to do so using the settings shown here.
I thought that selecting "Automatically continue after evaluating" might keep the debugger from stopping. It didn't.
I also tried issuing cont to the debugger after stopping. This doesn't seem to work either.
Can anyone you advise me on what settings I should enter here to keep the debugger from stopping on my EXC_ARITHMETIC exception?
That's an integer "division by zero" error exception. They aren't propagated as C++ exceptions as far as I'm aware, which is why you can't not break on them.
Does that happen even if your plugin isn't loaded? If it doesn't, your plugin is causing a division by zero somehow.
I followed the links suggested by #user1118321. After several hours of head scratching, I couldn't figure out how to either turn off or handle the integer division by zero exception. If anyone has any ideas I'd be happy to hear them.
I did find a workaround, though, which is to use GDB instead of XCode. Unlike XCode, GDB doesn't seem to stop on the EXC_ARITHMETIC and lets me step into my code. So, for the time being I'm going to switch over to GDB for debugging.
EDIT
A second (better) workaround, in my case, involved suspending the thread that was throwing the exception. This also allowed me to step through my plugin's code.
I'm writing a C++ Software Image processing tool.The tool works fine, but suddenly it stops and it never sends any exception or any crash or nothing that can let me which line or which area that does that crash.
How can I determine that faulty code in that situation?
There's a few things you can do:
First of all though, it sounds more like an infinite loop, deadlock, or like you're using all of your system resources and it's just slowing down and taking a very (possibly infinite) long time. If that's the case, you'll have to find it with debugging.
Things that you can try - not necessarily in this order:
Look for shared variables you're using. Is there a chance that you
have a deadlock with threads and mutexes? Think about it and try to
fix it.
Check for use of uninitialized variables/pointers. Sometimes
(rarely) you can get very strange behavior when you invoke undefined
behavior - I'm not a windows C++ dev (I work on Linux), but it
wouldn't be the first time I saw a lockup from a segmentation fault.
Add error output (std::cerr/stderror) to your processing logic so
you can see how far in it crashes. After that, set a condition to
catch it around that point so you can watch it happen in the
debugger and see the state of your variables and what might be
wrong.
Do a stack trace so you can see what calls have been hit most
recently. This will at least let you know the last function chain
that executed.
Have you used stack tracing before?
Look up MSDN documentation on how to use them. They have different type of stack trace depending on your application.
You could
Use a debugger
Add logging code to your program
Cut sections of code from your program until it starts working
Start with the first.
I am debugging (in Visual Studio 2008) a utility I have written in C++. Combining massive input files with my slow machine and it can take upwards of 6 hours to get to the point where I need to watch the program execution for irregularities.
I am probably grasping at straws here, but is anyone aware of feature or plugin or something within Visual Studio or something of the like where I can save program execution state so that I can bypass the time it takes to get where I need to be?
I'm not sure of possibilities within Visual Studio for doing such a thing, but if you can't find anything I would try using a Virtual Machine and saving the state of the machine.
It will probably be horribly slow but may help in the long run.
Good luck
What you need is a conditional breakpoint... see this url for more details:
http://msdn.microsoft.com/en-us/library/7sye83ce%28v=VS.90%29.aspx
The idea is that you know what conditions are true for the breakpoint to become valid, then when those conditions are true the breakpoint will trigger, pausing execution. You can then come along in the morning and begin to step through the code.
If you DO have an exact point that you want to cause a break at you can put in a programmatic break point DebugBreak() which will cause a break point exception to be thrown. The Visual Studio debugger will catch it and pause execution at that point.
Alternatively, enable gflags run the program with ADPlus and at the point of the code that you think has caused the problem throw an exception which is not handled. Let the program crash and ADPlus will generate a full crash dump of the process memory. The fact that you had gflags enabled means you will get memory allocations with nice borders around them (0xCDCDCDCD usually) for easy debugging.
Finally you can also use the DbgHelp.dll library from Microsoft to generate a mini-dump which can capture various levels of information programmatically (without a crash as the solution above entails). The function you want is MiniDumpWriteDump. You can write a normal mini-dump or a full memory dump using the parameters. This should be done from a separate process if possible (you can await the handle in your own process).
I've stumbled onto a very interesting issue where a function (has to deal with the Windows clipboard) in my app only works properly when a breakpoint is hit inside the function. This got me wondering, what exactly does the debugger do (VS2008, C++) when it hits a breakpoint?
Without directly answering your question (since I suspect the debugger's internal workings may not really be the problem), I'll offer two possible reasons this might occur that I've seen before:
First, your program does pause when it hits a breakpoint, and often that delay is enough time for something to happen (perhaps in another thread or another process) that has to happen before your function will work. One easy way to verify this is to add a pause for a few seconds beforehand and run the program normally. If that works, you'll have to look for a more reliable way of finding the problem.
Second, Visual Studio has historically (I'm not certain about 2008) over-allocated memory when running in debug mode. So, for example, if you have an array of int[10] allocated, it should, by rights, get 40 bytes of memory, but Visual Studio might give it 44 or more, presumably in case you have an out-of-bounds error. Of course, if you DO have an out-of-bounds error, this over-allocation might make it appear to be working anyway.
Typically, for software breakpoints, the debugger places an interrupt instruction at the location you set the breakpoint at. This transfers control of the program to the debugger's interrupt handler, and from there you're in a world where the debugger can decide what to do (present you with a command prompt, print the stack and continue, what have you.)
On a related note, "This works in the debugger but not when I run without a breakpoint" suggests to me that you have a race condition. So if your app is multithreaded, consider examining your locking discipline.
It might be a timing / thread synchronization issue. Do you do any multimedia or multithreading stuff in your program?
The reason your app only works properly when a breakpoint is hit might be that you have some watches with side effects still in your watch list from previous debugging sessions. When you hit the break point, the watch is executed and your program behaves differently.
http://en.wikipedia.org/wiki/Debugger
A debugger essentially allows you to step through your source code and examine how the code is working. If you set a breakpoint, and run in debug mode, your code will pause at that break point and allow you to step into the code. This has some distinct advantages. First, you can see what the status of your variables are in memory. Second, it allows you to make sure your code is doing what you expect it to do without having to do a whole ton of print statements. And, third, it let's you make sure the logic is working the way you expect it to work.
Edit: A debugger is one of the more valuable tools in my development toolbox, and I'd recommend that you learn and understand how to use the tool to improve your development process.
I'd recommend reading the Wikipedia article for more information.
The debugger just halts execution of your program when it hits a breakpoint. If your program is working okay when it hits the breakpoint, but doesn't work without the breakpoint, that would indicate to me that you have a race condition or another threading issue in your code. The breakpoint is stopping the execution of your code, perhaps allowing another process to complete normally?
It stops the program counter for your process (the one you are debugging), and shows the current value of your variables, and uses the value of your variables at the moment to calculate expressions.
You must take into account, that if you edit some variable value when you hit a breakpoint, you are altering your process state, so it may behave differently.
Debugging is possible because the compiler inserts debugging information (such as function names, variable names, etc) into your executable. Its possible not to include this information.
Debuggers sometimes change the way the program behaves in order to work properly.
I'm not sure about Visual Studio but in Eclipse for example. Java classes are not loaded the same when ran inside the IDE and when ran outside of it.
You may also be having a race condition and the debugger stops one of the threads so when you continue the program flow it's at the right conditions.
More info on the program might help.
On Windows there is another difference caused by the debugger. When your program is launched by the debugger, Windows will use a different memory manager (heap manager to be exact) for your program. Instead of the default heap manager your program will now get the debug heap manager, which differs in the following points:
it initializes allocated memory to a pattern (0xCDCDCDCD comes to mind but I could be wrong)
it fills freed memory with another pattern
it overallocates heap allocations (like a previous answer mentioned)
All in all it changes the memory use patterns of your program so if you have a memory thrashing bug somewhere its behavior might change.
Two useful tricks:
Use PageHeap to catch memory accesses beyond the end of allocated blocks
Build using the /RTCsu (older Visual C++ compilers: /GX) switch. This will initialize the memory for all your local variables to a nonzero bit pattern and will also throw a runtime error when an unitialized local variable is accessed.