This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Async signal safe TLS accesses
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Andrew Hunter <ahh at google dot com>, Rich Felker <dalias at aerifal dot cx>, GNU C Library <libc-alpha at sourceware dot org>, allan at archlinux dot org, "Carlos O'Donell" <carlos at redhat dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Date: Wed, 8 Jan 2014 19:11:31 -0800
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <52C4DC54 dot 4000109 at redhat dot com> <1388689454-1854-1-git-send-email-ahh at google dot com> <CALoOobPio5625ws7dSWepgQbKmqHifvbU3tKWtKFS-tz_zihdQ at mail dot gmail dot com> <CADroS=7BBPbJ5bAUUy5VUWHX+gCrRmrEk17qO-s9zkdVNeFbxA at mail dot gmail dot com> <20140103074522 dot GT24286 at brightrain dot aerifal dot cx> <CADroS=49b8c8KCiNF2cHHRk5nPmy8LzYYF_x=GZfOCCQORkx8A at mail dot gmail dot com> <CALoOobNz=FzbSkJdPMFwqnFdpyNcAy8vDDEftj+vbMT5r8mJAw at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401081752130 dot 1349 at digraph dot polyomino dot org dot uk> <CALoOobM6R+ua_0ffxRdaS_h69oUJ_+CoidxvLi+U_tdvJZY3dg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401082122230 dot 8625 at digraph dot polyomino dot org dot uk> <CALoOobMWsgbAjupv7Cj0-Xz0ND+TNinj26TquvEwZXM+BjfgiA at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401090233380 dot 8625 at digraph dot polyomino dot org dot uk>
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