How do I debug a core dump that aborted in a dlopen()'ed plugin?

Question

I have a core dump from a user. The main program loads selected plugins via dlopen. The process aborted in the plugin module. The user provided a backtrace that includes the filename of the plugin, and the function it aborted in.

I need to look at data, such as arguments passed to the function. How do I tell gdb where the plugin was loaded, so it can figure out how to show the source and data?

Answer 1

How do I tell gdb where the plugin was loaded, so it can figure out how to show the source and data?

GDB should do that automatically (the load addresses are contained inside the core).

All you need to do is supply the binaries that match customer's environment exactly. See also this answer.

Answer 2

If the core file is good then it should contain the call stack for the crash. You indicated that the crash occurred in the plugin module and function. By going 'up' the stack, you should be able to see the crash point and the containing function. In general, you should be able to look at the local variables including arguments to the function/method.

In short, just debug it like any other core file. Once the call to dlopen completes successfully, the shared library looks (nearly) the same as others loaded at start up.

If you share the bt, I can give some more definitive pointers.

As Employed Russian noted, you local executable and shared libraries must be bitwise the same as your clients. If the local version is different, it will throw off the mapping that gdb does between the core and the executable. This usually results rubbish but sometimes results in a stack that appears vaguely correct. As a result the programmer spends time chasing false leads. This situation is really aggravating!