30

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
  • 39,865
  • 32
  • 103
  • 160
  • I think this may be related: http://thread.gmane.org/gmane.comp.gdb.devel/24205 Any workarounds? – Alexander Gladysh Apr 24 '10 at 00:23
  • 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... ;-(. – Anna B Mar 05 '12 at 19:28

6 Answers6

30

This also works:

LD_PRELOAD=/lib/libpthread.so.0 gdb --args ./app
Josh Correia
  • 3,807
  • 3
  • 33
  • 50
ensonic
  • 3,304
  • 20
  • 31
28

64 bit Ubuntu users should do this:

LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0 gdb --args ./app
Brian
  • 622
  • 6
  • 10
15

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

set env LD_PRELOAD /lib/libpthread.so.0
DarthJDG
  • 16,511
  • 11
  • 49
  • 56
jbaylina
  • 4,408
  • 1
  • 30
  • 39
7

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...

Alexander Gladysh
  • 39,865
  • 32
  • 103
  • 160
  • When you say "suddenly" do you mean dynamic loading at runtime ? – Hassan Syed Sep 21 '10 at 13:13
  • 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. – Hassan Syed Sep 21 '10 at 13:20
  • @Hassan: yes, suddenly = dynamic loading – Alexander Gladysh Sep 21 '10 at 19:36
5

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

Gearoid Murphy
  • 11,834
  • 17
  • 68
  • 86
  • Sometimes recompiling is not a realistic option so attaching after is probably the more general solution. Thanks, this thread solved my problem. – Andrew Redd Oct 26 '10 at 00:55
2

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

Stas Yak
  • 109
  • 1
  • 3
  • 1
    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." ;) – Alexander Gladysh Sep 03 '13 at 18:30