This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?


On Fri, Sep 20, 2013 at 1:59 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>
> I've started a wiki page and I'll summarize people's comments there:
> https://sourceware.org/glibc/wiki/TLSandSignals

I tried to edit the page but I evidently don't have permissions (I
just created an account on the wiki IanLanceTaylor).

I don't think you characterized the problem precisely.  The issue is
not receiving a signal while the thread is initializing TLS.  The
general issue is that calling __tls_get_addr can call malloc, which is
not async-signal-safe.  A specific example would be

* There is an existing thread.
* The program does a dlopen of a shared library that uses TLS.
* The shared library installs a signal handler that refers to a TLS variable.
* The signal handler is called on the existing thread.
* Because shared library TLS variables are installed lazily, the
  existing thread does not yet have a copy of the TLS variable.
* Therefore the signal handlers TLS reference calls malloc.
* If the signal occurred during a call to malloc, we have a deadlock.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]