gdb: Cannot find new threads: generic error

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:    开发者_Go百科9.10
Codename:   karmic

This also works:

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

64 bit Ubuntu users should do this:

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

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

set env LD_PRELOAD /lib/libpthread.so.0

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

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

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