gdb: Cannot find new threads: generic error

Question

When I run GDB against a program which loads a .so which is linked to pthreads, GDB reports error "Cannot find new threads: generic error".

Note that executable that I run is not linked with pthreads.

Any clues?

$ gdb --args lua -lluarocks.require
GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/lua...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/lua -lluarocks.require
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio> require 'ev'
[Thread debugging using libthread_db enabled]
Cannot find new threads: generic error
(gdb) q
A debugging session is active.
 Inferior 1 [process 4986] will be killed.
Quit anyway? (y or n) y

This function gets called on require 'ev':

http://github.com/brimworks/lua-ev/blob/master/lua_ev.c#L25-65

Additional information about my system:

$ uname -a
Linux localhost 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 04:38:19 UTC 2010 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 9.10
Release: 9.10
Codename: karmic

• Alexander Gladysh: I think this may be related: thread.gmane.org/gmane.comp.gdb.devel/24205 Any workarounds?
• Gaspard Bucher: Thanks for the question... On my ubuntu system, I could not get preload /usr/lib/i386-linux-gnu/libpthread.so to work so I compiled Lua with pthread... ;-(.

Answer 1

This also works:

LD_PRELOAD=/lib/libpthread.so.0 gdb --args ./app

Answer 2

64 bit Ubuntu users should do this:

LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0 gdb --args ./app

Answer 3

You can also create a .gdbinit in your home directory containing this text:

set env LD_PRELOAD /lib/libpthread.so.0

Answer 4

It appears that GDB doesn't like when application "suddenly" becomes dependent on pthreads.

The only workaround I've found is to link host application with pthreads.

Which is rather sad...

• Hassan Syed: When you say "suddenly" do you mean dynamic loading at runtime ?
• Hassan Syed: This solved my problem as well, my static / shared libraries depend on pthread but not my executable therefore I do not link it in. However, once linked the debugger behaves properly... I should mention that my application does not create any threads, however it does have the potential to create objects in thread local memory.
• Alexander Gladysh: @Hassan: yes, suddenly = dynamic loading

Answer 5

I have found that gdb can attach to the process after the runtime linking to the pthreads library has completed.

• Andrew Redd: Sometimes recompiling is not a realistic option so attaching after is probably the more general solution. Thanks, this thread solved my problem.

Answer 6

"If you add flag -lpthread to gcc (or g++) while linking your application to be debugged the problem vanish." Source

• Alexander Gladysh: Well, this is more or less what I wrote as an answer three years ago: "The only workaround I've found is to link host application with pthreads." ;)