开发者

GDB (DDD), debugging questions

开发者 https://www.devze.com 2023-01-08 06:05 出处:网络
Some things in GDB (actually u开发者_运维技巧sing DDD gui) confuse me, when debugging my own C++ codes:

Some things in GDB (actually u开发者_运维技巧sing DDD gui) confuse me, when debugging my own C++ codes:

1) Why is there no backtrace available after a HEAP ERROR crash? 2) Why does gdb sometimes stop AFTER the breakpoint rather than AT the breakpoint? 3) Sometimes stepping through commented lines causes execution of some instructions (gdb busy)??

Any explanations greatly appreciated,

Petr


1) I'm not sure for heap error, but for example if you ran out of memory it might not be able to process the backtrace properly. Also if a heap corruption caused a pointer to blow up part of your application's stack that would cause the backtrace to be unavailable.

2) If you have optimization enabled, it's quite possible for this to happen. The compiler can reorder statements, and the underlying assembly upon which the breakpoint was placed may correspond to the later line of code. Don't use optimization when trying to debug such things.

3) This could be caused by either the source code not having been rebuilt before execution (so the binary is different from the actual source, or possibly even from optimization settings again.


Few possible explainations:

1) Why is there no backtrace available after a HEAP ERROR crash?

If the program is generating a core dump file you can run GDB as follows: "gdb program -c corefile" and get a backtrace.

2) Why does gdb sometimes stop AFTER the breakpoint rather than AT the breakpoint?

Breakpoints are generally placed on statements, so watch out for that. The problem here could also be caused by a mismatch between the binary and the code you're using.

3) Sometimes stepping through commented lines causes execution of some instructions (gdb busy)??

Again, see #2.


2) Why does gdb sometimes stop AFTER the breakpoint rather than AT the breakpoint?

Do you have optimization enabled during your compilation? If so the compiler may be doing non-trivial rearrangements of your code... This could conceivable address your number 3 as well.

With g++ use -O0 or no -O at all to turn optimization off.

I'm unclear of what your number 1 is asking.


Regarding the breakpoint and comment/instruction behavior, are you compiling with optimization enabled (e.g, -O3, etc.)? GDB can handle that but the behavior you are seeing sometimes occurs when debugging optimized code, especially with code compiled with aggressive optimizations.


  1. Heap checks are probably done after main returns, try set backtrace past-main in GDB. If it's crashing - the process is gone - you need to load the core file into debugger (gdb prog core).
  2. Optimized code, see @dmckee's answer
  3. Same as 2.
0

精彩评论

暂无评论...
验证码 换一张
取 消