WARNING: glibc dlopen threading bug

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

WARNING: glibc dlopen threading bug

William Ahern
Most distribution-packaged Lua interpreters are not linked against
libpthread.

On Linux I and some others still considered it relatively safe to use
multithreading from modules, presuming the modules linked in libpthread
themselves, because glibc goes to great lengths to permit linking of
libpthread into the process at runtime. With the possible exception of
strerror, the Lua VM doesn't use any APIs that aren't supposed to be
thread-safe in glibc, whether or not pthread was linked at startup time.

However, I've discovered a bug in dlopen/dlclose (dlerror, specifically) in
glibc that invalidates this tidy assumption. I've reported it here:

        https://sourceware.org/bugzilla/show_bug.cgi?id=18192

The problem with this bug in particular (unlike, e.g., [1]) is that it
totally breaks Lua modules like Lua Lanes, LuaExec, mqlua, or my own
cqueues.thread module. You can't safely spin up a thread which uses
lua_newstate and then proceeds to load modules. I think this bug goes mostly
undetected because the race normally requires either a module to fail to
load, or for dlclose to be called from multiple Lua VM states. Because
modules don't usually fail to load, and because threads tend to be
long-lived in most applications (using thread pools), this bug has flown
under the radar, perhaps with the occassional unexplained coredump.

I also stumbled across this bug report regarding getaddrinfo:

        https://sourceware.org/bugzilla/show_bug.cgi?id=10652

I also discovered a couple of other similar bugs. (See my bug report.)

The short-term solution to this, as on other platforms that require
libpthread to be loaded at startup time (BSDs), is to use LD_PRELOAD. I've
added multi-system LD_PRELOAD support to my runlua script:

        https://github.com/wahern/luapath

Use libpthread.so.0 for Linux/glibc. See the getpth routine in the runlua
script for the library name to load on other systems. Solaris, OS X, and
Linux/musl have unified libc/libphread implementations.

Long-term I think it would be better if Lua packagers linked the system
interpreter with -lpthread. It's what Perl, Ruby, Python, and Node.js do.

Reply | Threaded
Open this post in threaded view
|

Re: WARNING: glibc dlopen threading bug

Matthew Wild
On 3 April 2015 at 22:10, William Ahern <[hidden email]> wrote:
> Use libpthread.so.0 for Linux/glibc. See the getpth routine in the runlua
> script for the library name to load on other systems. Solaris, OS X, and
> Linux/musl have unified libc/libphread implementations.
>
> Long-term I think it would be better if Lua packagers linked the system
> interpreter with -lpthread. It's what Perl, Ruby, Python, and Node.js do.

Which would also solve this age-old problem with gdb:
http://stackoverflow.com/q/2702628/15996

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: WARNING: glibc dlopen threading bug

Enrico Tassi
In reply to this post by William Ahern
On Fri, Apr 03, 2015 at 02:10:12PM -0700, William Ahern wrote:
> Long-term I think it would be better if Lua packagers linked the system
> interpreter with -lpthread. It's what Perl, Ruby, Python, and Node.js do.

Thanks for the heads up! Debian adds "-lpthread" for Hurd, since it is
required, but does not add the flag on Linux (nor on FreeBSD).

Too bad Jessie is almost released.  It will be for Jessie+1.

Best,
--
Enrico Tassi

Reply | Threaded
Open this post in threaded view
|

Re: WARNING: glibc dlopen threading bug

Hisham
In reply to this post by Matthew Wild
On 3 April 2015 at 19:31, Matthew Wild <[hidden email]> wrote:

> On 3 April 2015 at 22:10, William Ahern <[hidden email]> wrote:
>> Use libpthread.so.0 for Linux/glibc. See the getpth routine in the runlua
>> script for the library name to load on other systems. Solaris, OS X, and
>> Linux/musl have unified libc/libphread implementations.
>>
>> Long-term I think it would be better if Lua packagers linked the system
>> interpreter with -lpthread. It's what Perl, Ruby, Python, and Node.js do.
>
> Which would also solve this age-old problem with gdb:
> http://stackoverflow.com/q/2702628/15996

Thanks for the heads up. Updated the GoboLinux recipe of Lua accordingly.

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: WARNING: glibc dlopen threading bug

Ed Maste
In reply to this post by Enrico Tassi
On 4 April 2015 at 08:44, Enrico Tassi <[hidden email]> wrote:
> On Fri, Apr 03, 2015 at 02:10:12PM -0700, William Ahern wrote:
>> Long-term I think it would be better if Lua packagers linked the system
>> interpreter with -lpthread. It's what Perl, Ruby, Python, and Node.js do.
>
> Thanks for the heads up! Debian adds "-lpthread" for Hurd, since it is
> required, but does not add the flag on Linux (nor on FreeBSD).

This issue is a property of the userland though -- Debian
GNU/kFreeBSD's using glibc and friends, not the FreeBSD userland.

In FreeBSD 11.0-CURRENT we no longer have the limitation that
libpthread must be loaded at startup. I tried the sample code attached
to the sourceware PR (with two trivial changes to get it to build on
FreeBSD) and it does not encounter any misbehaviour.

I haven't looked at the implementation of any related functionality,
though, and I'm not certain there aren't other, similar problems
lurking in FreeBSD.