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 16:42:09 -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>
On Wed, Jan 8, 2014 at 2:04 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> The problem doesn't reproduce under GDB. With a core dump I get the not
> particularly helpful backtrace:
>
> Core was generated by `./tst-tls7 --direct'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x0fdef838 in ?? ()
> (gdb) bt
> #0 0x0fdef838 in ?? ()
> #1 <signal handler called>
> #2 0x0fe999e0 in __GI___libc_malloc (bytes=bytes@entry=128) at malloc.c:2900
> #3 0x100016e4 in spin (ignored=<optimized out>) at tst-tls7.c:35
> #4 0x0ffa8d0c in start_thread (arg=0xf6a8b470) at pthread_create.c:311
> #5 0x0fefe704 in clone ()
> at ../sysdeps/unix/sysv/linux/powerpc/powerpc32/clone.S:102
Where line 2900 is this one, right?
2899 else
2900 (void) mutex_unlock (&ar_ptr->mutex);
2901 assert (!victim || chunk_is_mmapped (mem2chunk (victim)) ||
2902 ar_ptr == arena_for_chunk (mem2chunk (victim)));
2903 return victim;
2904 }
Could you "print *ar_ptr" in frame #2.
Does your compiler and/or configure force GNU2 TLS to be used?
(How did you configure? Which compiler did you use?)
GNU2 TLS has *not* been made async-signal-safe, and I suspect would fail
this test if enabled.
... testing that theory on x86_64 ... by configuring with
'CC=gcc -mtls-dialect=gnu2'. No luck :-(
If GNU2 TLS is not in the picture, then I think it's likely that the
patch(es) missed some path from TLS into malloc, and therefore arena
is getting corrupted by TLS access from within a signal. We'll need to
reproduce this here (fortunately we do have some ppc64 machines to do
that on).
Thanks,
--
Paul Pluzhnikov