GDB and issue

Avi Gozlan
Sun May 19 08:04:00 GMT 2013

Thanks doug.
Of course I have copied the 32bit /usr/lib/  to the target machine.

Yet following your emphasis on this specific file I double checked, and realized the /usr/lib/ file is merely a text file... not the real library. The real 32bit one resides in /lib, not in /usr/lib.

Copying /lib/ and /lib/ to the target resolved the problem.

Thanks a lot,


-----Original Message-----
From: Doug Evans [] 
Sent: Thursday, May 16, 2013 7:26 PM
To: Avi Gozlan
Subject: Re: GDB and issue

On Thu, May 16, 2013 at 5:30 AM, Avi Gozlan <> 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 and were copied from another machine, both are located in /lib64. (for the sake of trouble shooting I replaced also and 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/
> #3  0x00000031542020b5 in td_ta_thr_iter () from 
> /lib64/
> #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?

Email secured by Check Point

More information about the Gdb mailing list