Related
I have an application, which is running for a long time and then crash. I need to debug it several times to fix it and don't want to wait every time for an hour to reach the state, in which an error is occurred.
So, I want some tool to clone the whole process on a disk, then raise it, attach to it and debug.
I use Visual Studio 2012/2013 on (surprise) Windows.
For example:
for (int i = 0; i < 10000; ++i)
{
if (i == 9999)
throw MyExcept();
}
And I want to have a saved state of application (process) at 9998-th iteration to start debugging from it.
UPD 1: Visual Studio dump files are not admirable, because I can't get all functionality of debugger after opening it it VS. For example: I can't set breakpoints and even old ones don't work.
UPD 2: Also I need to have a possibility of duplicating this saves session of the app.
If I understood correctly, you want to accomplish two tasks:
1) Break the execution on a specific condition
You need to set a watchpoint with a condition to achieve this, or Data Breakpoint in Visual Studio terms. Have a look at this question: Can I set a breakpoint when variable is getting a specific value in .NET?
2) Dump a core file
Once you have set the watchpoint and your program reached that point, you can dump a core file. From that you can continue with the execution later on. There is an official FAQ entry entry on how to dump and load cores.
You need procdump from here
Register as the Just-in-Time (AeDebug) debugger.
Perhaps you should enable full local dumps.
Crash you program
Launch a process with procdump from full dump
But I think it is better to use DebugBreak API in your example without a crash.
Usually crash will not allow you to start further - only postmortem analysis.
I finally succeed remote debugging from my windows machine to remote linux binary.
I can almost do everything except few things. Forexample I can't insert break points by enabling breakpoint of line by mouse click. But if I write :
b main
Note: breakpoint 1 also set at pc 0x401378.
Breakpoint 2 at 0x401378: file src/test.cpp, line 18.
to the eclipse console breakpoint,break point working.
Does anyone has any idea about that? Why UI breakpoint is not working .
Secondly lets say I add break point to line 12.(it happens very often any point in program 12 is just a example) When I "continue", I am not being able to execute "next","step" or view variables but if I put one more break point to one line after line 13 and "continue" everything is back normal again. I am again being able to use "next","step" etc...
This is disturbing me because I need to add unnecessary break points for this situation.
Any help will be appriaciated about those two problems related with remote debugging with eclipse UI.
I am currently developing a distributed software in C++ using linux which is executed in more than 20 nodes simultaneously. So one of the most challenging issue that I found is how to debug it.
I heard that is possible to manage in a single gdb session multiple remote sessions (e.g. in the master node I create the gdb session and in every other node I launch the program using gdbserver), is it possible? If so can you give an example? Do you know any other way to do it?
Thanks
You can try to do it like this:
First start nodes with gdbserver on remote hosts. It is even possible to start it without a program to debug, if you start it with --multi flag. When server is in multi mode, you can control it from your local session, I mean that you can make it start a program you want to debug.
Then, start multiple inferiors in your gdb session
gdb> add-inferior -copies <number of servers>
switch them to a remote target and connect them to remote servers
gdb> inferior 1
gdb> target extended-remote host:port // use extended to switch gdbserver to multi mode
// start a program if gdbserver was started in multi mode
gdb> inferior 2
...
Now you have them all attached to one gdb session. The problem is that, AFAIK, it is not much better than to start multiple gdb's from different console tabs. On the other hand you can write some scripts or auto tests this way. See the gdb tutorial: server and inferiors.
I don't believe there is one, simple, answer to debugging "many remote applications". Yes, you can attach to a process on another machine, and step through it in GDB. But it's quite awkward to debug a large number of interdependent processes, especially when the problem is complicated.
I believe a good set of logging capabilities in the code, supplemented with additional logs for specific debugging as needed, is more likely to give you a good/fast result.
Another option might be to run the processes on one machine, rather than on multiple machines. Perhaps even use threads within one process, to simulate the behaviour of multiple machines, simplifying the debugging process. Of course, this doesn't prevent bugs that appear ONLY when you run 20 processes on 20 different machines. But the basic idea is to reduce the number of those bugs to a minimum, and debug most things in a "simpler environment".
Aggressive use of defensive programming paradigms, such as liberal use of assert is clearly a good idea (perhaps with a macro to turn it off for the production runs, but make sure that you don't just leave error paths completely unchecked - it is MUCH harder to detect that the reason something crashes is that a memory allocation failed than to track down where that NULL pointer came from some 20 function calls away from a failed allocation.
I am trying to extract the execution sequence of my program (something like a program counter) with gdb on my local computer (windows x86) and gdbserver on a remote target (arm-linux). The idea I had was to insert breakpoints at "important" lines of my source files (i.e.: at the beginning of a specific function, and more in general before and after a conditional statement) with a high ignore count for each breakpoint, and then check if a breakpoint was hit or not. I was actually able to receive the informations with this method, but there is a problem: the application behavior I am debugging depends on real-time, and this specific method slows down the program execution too much. Do you think I could use some other method with gdb? I stumbled upon tracepoints, wich seems the exact thing I am looking for, but I was not able to find some property like a "hit counter" for them. The gdb version I am currently using is 7.5.
Thanks a lot in advance.
If your program execution must not be slowed down, you will probably need some HW tool. See these:
Keil real time trace
Lauterbach PowerDebug
(probably other similar solutions)
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.