This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB and libthread_db.so.1 issue
- From: Doug Evans <dje at google dot com>
- To: Avi Gozlan <avi at checkpoint dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Thu, 16 May 2013 09:26:22 -0700
- Subject: Re: GDB and libthread_db.so.1 issue
- References: <71C49BB0B847984EAADFE43F93C6BF081196ED31 at IL-EX10 dot ad dot checkpoint dot com>
On Thu, May 16, 2013 at 5:30 AM, Avi Gozlan <avi@checkpoint.com> wrote:
> Hello,
>
> I have got a problem with debugging 32bit applications on a target x86_64 machine.
>
> I use 64bit gdb 7.1 on a x86_64 machine (running 'file `which gdb`' returns ELF 64-bit LSB executable, AMD x86-64...)
> I can debug 64bit applications successfully on this target machine. However, when trying to debug 32bit applications, I get the following error message:
> Cannot find new threads: generic error
>
> Both libpthread.so.0 and libthread_db.so.1 were copied from another machine, both are located in /lib64. (for the sake of trouble shooting I replaced also libc.so.6 and ld-linux-x86.so.2 with libraries copied from that same machine).
>
> When debugging gdb itself, I saw that indeed these shared libraries are loaded by gdb (by running 'info shared'). Yet debugging fails with 32bit programs. The top of the gdb's backtrace for the failure is the following:
>
> #0 thread_db_err_str (err=TD_ERR) at linux-thread-db.c:264
> #1 0x0000000000497897 in find_new_threads_callback (th_p=0x7fffffffb760,
> data=0x7fffffffb840) at linux-thread-db.c:1306
> #2 0x0000003154202000 in iterate_thread_list () from /lib64/libthread_db.so.1
> #3 0x00000031542020b5 in td_ta_thr_iter () from /lib64/libthread_db.so.1
> #4 0x0000000000497aea in find_new_threads_once (info=0xd38a50, iteration=0,
> errp=0x7fffffffb8c0) at linux-thread-db.c:1378
> #5 0x0000000000497ccc in thread_db_find_new_threads_2 (ptid=...,
> until_no_new=0) at linux-thread-db.c:1445
> #6 0x0000000000497d2b in thread_db_find_new_threads_1 (ptid=...)
> at linux-thread-db.c:1454
> #7 0x00000000004976d9 in thread_db_wait (ops=0xb21ca0, ptid=...,
> ourstatus=0x7fffffffbad0, options=0) at linux-thread-db.c:1247
> #8 0x0000000000588734 in target_wait (ptid=..., status=0x7fffffffbad0,
> options=0) at target.c:2132
> #9 0x0000000000551de6 in wait_for_inferior (treat_exec_as_sigtrap=0)
> at infrun.c:2270
> #10 0x0000000000551468 in proceed (addr=18446744073709551615,
> siggnal=TARGET_SIGNAL_0, step=0) at infrun.c:1896
> #11 0x000000000054ad68 in run_command_1 (args=0x0, from_tty=1,
> tbreak_at_main=0) at infcmd.c:585
> #12 0x000000000054ad9b in run_command (args=0x0, from_tty=1) at infcmd.c:595
> #13 0x00000000004bc730 in do_cfunc (c=0xb80070, args=0x0, from_tty=1)
>
> It appears that the libthread_db library is called by gdb but identifies a problem. As said, the very same libraries are loaded by gdb for a successful 64bit applications debugging.
>
> I would be thankful if you could shed light on this issue.
It's unfortunate that libthread_db errors aren't more descriptive. I
hate debugging these issues too.
Note that libpthread is linked into the app and libthread_db is loaded by gdb.
And they need to match.
You say you copied libpthread from another machine, but did you *also*
copy the 32-bit version of libpthread from the other machine?