11

My program links statically to many libraries and crashes before getting to main in GDB. How do I diagnose what the problem is?

janw
  • 8,758
  • 11
  • 40
  • 62
chacham15
  • 13,719
  • 26
  • 104
  • 207

7 Answers7

13

It's a good bet that LD_DEBUG can help you here. Try this: LD_DEBUG=all ./a.out. This will allow you to easily identify the library which is being loaded when your program crashes.

(Edit: if it wasn't clear, a.out is meant to refer to a generic binary file -- in this case, replace it with the name of your executable).

Edit 2:

To clarify, LD_DEBUG is an environment variable which is examined by the dynamic linker when a program begins execution. If LD_DEBUG is set to some value, the dynamic linker will output a lot of information about the dynamic libraries being loaded during program execution, symbol binding, and so on.

For starters, execute the following on your machine:

LD_DEBUG=help ls

You will see the valid options for LD_DEBUG on your system listed. The most verbose setting is all, which will display all available information.

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

tdenniston
  • 3,389
  • 2
  • 21
  • 29
  • how exactly do I add this? that doesnt look like a gdb function – chacham15 Oct 18 '11 at 16:06
  • 2
    @denniston.t, `LD_DEBUG` is for debugging shared libraries, but here program is linked statically. It will not help if the bug is in static library. – ks1322 Oct 18 '11 at 16:22
  • @ks1322: Whoops, I missed that part of the question. Thanks for pointing it out. – tdenniston Oct 18 '11 at 16:24
  • 1
    could you please explain anyways, it may well be that the statically linked libraries themselves link other libraries dynamically – chacham15 Oct 18 '11 at 17:05
  • @chacham15: I've updated my answer with more details: it isn't a gdb command, but an environment variable you specify upon executing your program. – tdenniston Oct 18 '11 at 17:42
4

starti

starti breaks at the very first instruction executed, see also: Stopping at the first machine code instruction in GDB

An alternative if your GDB is not new enough:

break _start

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

info files

search for Entry point:

 Entry point: 0x400440

and run:

 break *0x400440

TODO: find out how to compile crt* objects with debug symbols and step into them: How to compile my own glibc C standard library from source and use it?

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
4

It may crash because some component throws an exception and nobody catches it since main() hasn't been entered yet. Set a breakpoint on throwing an exception:

catch throw
run

(If catch throw doen't work the first time you start it, run it once to let it load the dynamic libraries and then do catch throw and run again).

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
4

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

Community
  • 1
  • 1
TJD
  • 11,800
  • 1
  • 26
  • 34
  • Function "__libc_start_main" not defined. – chacham15 Oct 18 '11 at 17:07
  • 1
    your program will have something similar. you can find out what your actual execution entry point is by running readelf -h on your executable. You can set a breakpoint on the Entry point address it shows you. – TJD Oct 18 '11 at 17:23
  • the problem with this is once it stopped, i have no way to 'iterate through the libraries'. – chacham15 Nov 05 '11 at 13:09
3

Start taking the libraries out one by one until it stops crashing. Then examine the culprit.

MK.
  • 33,605
  • 18
  • 74
  • 111
  • 4
    Really? That's not particularly realistic. Some programs are large and removing a library means lots of references that will now no longer link. – Joe Oct 18 '11 at 14:31
  • 2
    @Joe yeah, sometimes you have to actually, you know, do difficult things. You have a better suggestion? – MK. Oct 18 '11 at 14:33
  • 1
    Or use `LD_DEBUG` as a shortcut to help accomplish the same thing (see my answer). – tdenniston Oct 18 '11 at 15:28
  • 1
    It was annoying and took a reeeealy long time, but this is what i did. – chacham15 Nov 05 '11 at 13:09
2

I haven't run into this in C but if you link to a c++ library static initialization can crash. You can create it easily by having an assert in a constructor of a static scope variable.

rerun
  • 25,014
  • 6
  • 48
  • 78
2

If you can, link your program dynamically instead of statically and follow @denniston.t answer. Maybe debug trace from dynamic linker will help to fix this problem.

Community
  • 1
  • 1
ks1322
  • 33,961
  • 14
  • 109
  • 164