How to debug a failure before the main?

My program statically links to many libraries and crashes before moving to the main one in gdb. How do I diagnose a problem?

+7
source share
7 answers

Start taking libraries one by one until the crash stops. Then inspect the culprit.

+3
source

Good thing LD_DEBUG can help you. Try the following: LD_DEBUG=all ./a.out . This will allow you to easily identify the library that loads when your program crashes.

(Edit: if this was not clear, a.out means a link to a shared binary - in this case, replace it with the name of the executable).

Edit 2:

To clarify, LD_DEBUG is an environment variable that is considered by the dynamic linker when the program starts. If a LD_DEBUG set for the LD_DEBUG parameter, the dynamic linker will provide a lot of information about dynamic libraries loaded at runtime, symbol bindings, etc.

To start, run the following on your computer:

 LD_DEBUG=help ls 

You will see the valid parameters for LD_DEBUG on your system. The most difficult setting is all , which displays all the available information.

Now, to use it as simple as the ls example, replace ls with your program name. There is no need for gdb to use LD_DEBUG, as this is functionality provided exclusively by the dynamic linker, not gdb.

+9
source

This post has an answer, you must set a breakpoint before main in the crt0 startup code: Using GDB without debugging characters on x86?

+3
source

I have not come across this in C, but if you reference the C ++ library, static initialization may crash. You can easily create it by specifying scope in the constructor of a static variable.

+2
source

This can lead to a failure, because some component throws an exception, and no one catches it, since main() has not yet been introduced. Set a breakpoint when throwing an exception:

 catch throw run 

(If catch throw does not work the first time you run it, run it once so that it loads the dynamic libraries, then execute catch throw and run it again).

+2
source

If you can, dynamically link your program instead of statics and follow @ denniston.t answer . Perhaps debugging the trace from the dynamic linker will help fix this problem.

+1
source

To stop the first command, follow these steps:

 break _start 

if you know that the entry point method name is _start or:

 info files 

find the Entry point :

  Entry point: 0x400440 

and run:

  break *0x400440 

Adapted from a subset question: Stopping on first machine code instruction in GDB

0
source

All Articles