[PATCH] Async signal safe TLS accesses

[Paul Pluzhnikov]

On Wed, Jan 8, 2014 at 6:40 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:

> If the <signal handler called> backtrace is correct, and the main thread
> backtrace in dlclose is also correct, I don't understand how a signal
> handler should be executing in one thread while dlclose is executing
> (indeed, the lack of a function name in the backtrace with the signal
> handler would be explained by it executing the handler located in a module
> that's in the process of being unloaded).

Oh, I assumed that the SIGSEGV was generated in frame 2, but it may have
just been SIGUSR1 instead, and the actual crash is in fact in frame 0 that
has just been unmapped (on line 639 of dl-close.c in the other thread).

Could you switch to the other thread and print *imap?

> So I wonder if there could be
> something wrong with sem_wait / sem_post on powerpc (which has its own
> sem_post variant), causing dlclose to execute when not all threads have
> finished handling the signal, although I haven't managed to identify a bug
> there (and one might expect such a bug to cause more than just this one
> new test to fail).

I think I see a race in the test case itself (time goes down):

  T1                             T0
  spin
   malloc
                                 pthread_sigqueue
    ... gets SIGUSR1
     action (handler)
                                 sem_wait  blocks
      sem_post
                                 sem_wait returns
                                 dlclose
                                   munmap -- blows away DSO with action()

      sem_post returns ...
     ... to action() that has just been munmapped.


If this is correct, putting sleep(1) before dlclose() should make it go
away. Not sure what the propoer fix is ...

-- 
Paul Pluzhnikov