Unable to Debug Multi-Threaded Application with gdb

Question

I am debugging a multi-threaded application with gdb, but when I start the program in gdb I get the warning:

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

I can still debug, but I can't debug anything other than the main thread. I have read forums that suggest installing the packages libthread-db1 and glibc-dbg, but this does not correct the problem for me.

On my machine I have the 3 files /lib/libthread_db.so.1, /lib/.debug/libthread_db-1.0.so, and /lib/libthread_db-1.0.so. I tried creating symbolic links in /lib with the name libthread_db.so, one time pointing at the /lib/libthread_db.so.1 file, and another time pointing at the /lib/libthread_db-1.0.so file, and also I created the symbolic link /lib/.debug/libthread_db.so pointing to /lib/.debug/libthread_db-1.0.so, all with no luck.

In gdb I have tried setting libthread-db-search-path to /lib (with the symlink once set to libthread_db.so.1, and once to libthread_db-1.0.so, and also set to /lib/.debug.

Any suggestions? I am using Angstrom Linux v2.6.39 for the BeagleBoard-xm.

Marketa

Note that I started with a root file system from a 2.6.32 kernel (Angstrom-Beagleboard-demo-image-glibc-ipk-2011.1-beagleboard.rootfs.tar.bz2), and copied the linux source into /usr/src, and cross-compiled a new kernel based on 2.6.39. This is likely the reason for the version mismatch. I have the threading shared object files from the cross compiler, and I tried replacing the existing .so files with the ones from the cross compiler, but it caused make to crash. Any ideas? – Marketa

Hi I'm currently having the exact same issue on angstrom running on a beaglebone. Did you ever figure out the solution? – Thesis

Also, be sure your version of libpthread is not stripped – Underpants

Answer 1

warning: Unable to find libthread_db matching inferior's thread library

This means that your /lib/libthread_db.so.1 does not match your /lib/libpthread.so.0. Such mismatch could be the result of you installing different versions of libc and libthread_db packages, or updating one or the other outside of the package management system. It could also be an error in your packages (i.e. they may not be built correctly).

You should ignore /lib/.debug/* -- that is not the library you are looking for.

Cushy

Answer 2

You are correct in trying to use

set libthread-db-search-path [path]

however, it seems you have still not pointed it at a version of libthread_db that is compatible with the pthreads library you're using.

First, check which pthread library you're linked to using ldd:

ldd your_executable

then make sure the libthread-db-search-path points to a location that has a compatible version of libthread_db with whatever libpthread you're getting. It could be that you're dynamic linker path is getting a different pthread library than you expect.

Blanchblancha

This is quite old topic but just a suggestion: instead of ldd you can use readelf. – Megaera

compatible version of libthread_db How do we find this? – Peculiarize

Answer 3

If you run your process in docker container, please restore your coredump also in container!

I add my case and solution here, which may help someone.

The process is deployed to run in docker container, and then I crash it with kill -3. The compressed coredump file will be generated according to my settings.

When the coredump file is decompressed from my Host OS, then GDB in docker will give WARNING:

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

And GDB can show nothing useful information.

When the coredump file is decompressed from the container, then the above warning is fixed with:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

And GDB can successfully show debug information like stack trace.

Plaything