I have a C++ application where somehow, gdb (I'm using the mingw-w64 version) always seems to be confused about what address the main executable is loaded at. If I try to insert a breakpoint on some function or file+line number, gdb tries to do it at the wrong address and the breakpoint doesn't work. It also can't produce backtraces. I can see that the address it uses is wrong by adding a printf showing the address of some function, and comparing it with the one gdb uses with break someFunction (or print &someFunction). On the other hand, for functions located in DLLs, gdb can successfully insert a breakpoint or produce a backtrace (at least until a function in the executable is reached).
I don't know why this happens, but it would be nice to be able to use the debugger anyway. Assuming the hypothesis of a wrong address for the executable's code segment, is there some way I can adjust it to be at the right place? The gdb versions I've tried are 7.9 and 8.0.1.
Related
I want to attach a command to a breakpoint that writes a full callstack to a file every time the breakpoint is hit. Since I know that this may hit performance hard, I want to print out the information as condensed as possible. However, the bt command always prints a lot of info, like symbols, line in a file etc.
Is there an alternative to bt that prints out as little as possible while still allowing to reconstruct the call hierarchy after debugging has finished? Like, only printing out the instruction pointers of the functions in the stack?
Regards
Since I know that this may hit performance hard, I want to print out the information as condensed as possible.
It's not printing the information that is slow. The mere fact that you hit a breakpoint will already slow down your program immensely (if the breakpoint is hit often).
Like, only printing out the instruction pointers of the functions in the stack?
You don't need GDB for that. On many platforms the program can obtain this info directly (e.g. from backtrace function) and log it to disk. That is usually at least a 100 times faster than doing it in GDB.
the bt command always prints a lot of info, like symbols, line in a file etc.
You can control exactly what is printed with a Python unwinder or frame decorator.
You can remove all debug info from the binary you are debugging using strip tool.
bt should work fast on binary without symbols, you will not get any line numbers or function names, only raw memory addresses in bt output. If you are going to set breakpoint you will have to set it on memory address as there is no debug info anymore in binary.
To reconstruct the call hierarchy after debugging has finished you can use addr2line, see this question: How to use addr2line command in linux. I don't know automated way of resolving all addresses in bt output. Probably you will have to resolve them one by one or write a script to do it automatically. Note that now the binary should be unstripped (with debug symbols).
Using Steam Crash reporting service and we have an error that is
Win32 StructuredException at 00C6A290 : Attempt to read from virtual
address 5467 without appropriate access rights.
I think I understand the second part (the program read memory from an area that it should not have). But the first part I don't understand. Is 00C6A290 the same each time the program is executed (and does I can backtrace it somehow) or is it assigned by the program at runtime.
It looks like 00C6A290 is an address in memory (within the executable of your program or some code called from it). To my understanding this address is the address of the instruction which caused the exception. In general it may be different each time you run your program since it can be loaded to different memory regions by the OS.
Run your program in a debugger to see backtrace. Do you have the source code?
GDB breakpoints won't work after the function address changed. Is it possible to tell gdb to relocate the function address when running the program?
GDB breakpoints won't work after the function address changed
That depends on how you set a breakpoint.
If you did break *0x12345, then you must update the breakpoint if on re-build and re-run the address you care about is different.
On the other hand, if you did break foo, and the &foo changes due to a re-build, GDB will automatically reset the breakpoint on the new address on re-run. (If GDB doesn't do it for you, that's a bug in GDB.)
A basic question & I am very new to C/C++ and GDB.
We use GDB to debug a process. We attach GDB to a process and then specify filename.c along with line number to put break point.
My question is "How would GDB or OS OR possibly anything else know that it has to break at specified line number (in filename.c) after we connect GDB to running process?"
What is coming into picture that, say, the current process is run in debug mode and a breakpoint is applied and the process execution has to break (wait for user input) at that point?
The same way that if your program stops or crashes at a particular point, the debugger can tell you where in the program that point is.
For both of these to work the program binary must contain additional debugging information that associates addresses in the program image with locations in the source code (source file and line number.)
To add a breakpoint at a particular line the debugger finds the program address closest to that line, modifies the copy of the executable in memory to insert a special "break" instruction at that location which will cause the program's execution to be interrupted, then "traces" the program's execution and waits for it to reach the breakpoint and stop.
For more details see http://eli.thegreenplace.net/2011/01/23/how-debuggers-work-part-1/ and http://www.howzatt.demon.co.uk/articles/SimplePTrace.html
I can't comment for the latest version of gdb - but many debuggers actually swap the assembly instruction at the desired breakpoint location (in memory) with an interrupt instruction. This "wakes up" the debugger which takes control at this point.
Using a substituted interrupt instruction means that the CPU can execute your program at full speed and "trip up" at the desired location.
Modern processors are very complex, however, and probably have far superior debugging features.
GDB is aware of your code : it knows all about it. When you set a breakpoint at a line, GDB gets the equivalant machine instruction address : all your code (as machine instructions) is loaded in memory, so the instructions of your code have an address.
So now GDB knows the adress of the instruction you want to break. When you run your programm, GDB will use ptrace, which allow GDB to "see" each instructions before their execution. Then GDB have just to look if the current instruction (which will be executed) is the same as your instruction (that you want to break).
Is there a way for my code to be instrumented to insert a break point or watch on a memory location that will be honored by gdb? (And presumably have no effect when gdb is not attached.)
I know how to do such things as gdb commands within the gdb session, but for certain types of debugging it would be really handy to do it "programmatically", if you know what I mean -- for example, the bug only happens with a particular circumstance, not any of the first 11,024 times the crashing routine is called, or the first 43,028,503 times that memory location is modified, so setting a simple break point on the routine or watch point on the variable is not helpful -- it's all false positives.
I'm concerned mostly about Linux, but curious about if similar solutions exist for OS X (or Windows, though obviously not with gdb).
For breakpoints, on x86 you can break at any location with
asm("int3");
Unfortunately, I don't know how to detect if you're running inside gdb (doing that outside a debugger will kill your program with a SIGTRAP signal)
GDB supports a scripting language that can help in situations like this. For example, you can trigger a bit of custom script on a breakpoint that (for example) may decided to "continue" because some condition hasn't been met.
Not directly related to your question, but may be helpful. Have you looked at backtrace and backtrace_symbol calls in execinfo.h
http://linux.die.net/man/3/backtrace
This can help you log a backtrace whenever your condition is met. It isn't gdb, so you can't break and step through your program, but may be useful as a quick diagnostic.
The commonly used approach is to use a dummy function with non-obvious name. Then, you can augment your .gdbinit or use whatever other technique to always break on that symbol name.
Trivial dummy function:
void my_dummy_breakpoint_loc(void) {}
Code under test (can be an assert-like macro):
if (rare_condition)
my_dummy_breakpoint_loc();
gdb session (obvious, eh?):
b my_dummy_breakpoint_loc
It is important to make sure that "my_dummy_breakpoint_loc" is not optimized away by compiler for this technique to work.
In the fanciest of cases, the actual assembler instruction that calls my_dummy_breakpoint_loc can be replaced by "nops" and enabled on site by site basis by a bit of code self-modification in run-time. This technique is used by Linux kernel development instrumentation, to name a one example.