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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Paul Pluzhnikov <ppluzhnikov at google 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 22:04:06 +0000
- 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>
On Wed, 8 Jan 2014, Paul Pluzhnikov wrote:
> On Wed, Jan 8, 2014 at 9:53 AM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> > I'm seeing tst-tls7 failing for powerpc32, both soft-float (testing with
> > GCC mainline) and hard-float (testing with GCC 4.7). The failure is
> > "Didn't expect signal from child: got `Segmentation fault'". Adhemerval,
> > are you seeing this?
>
> Could you run the test under GDB with --direct and get a stack trace
> from the crash?
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
The main thread's backtrace at this point is:
#0 0x0ff0da78 in __lll_lock_wait_private (futex=0x200,
futex@entry=0xff8d31c <main_arena>)
at ../nptl/sysdeps/unix/sysv/linux/lowlevellock.c:30
#1 0x0fe97144 in _int_free (av=0xff8d31c <main_arena>, p=0x10014000,
have_lock=0) at malloc.c:3940
#2 0xf7aa15a8 in _dl_close_worker (map=map@entry=0x100141a0) at
dl-close.c:660
#3 0xf7aa1d28 in _dl_close (_map=0x100141a0) at dl-close.c:781
#4 0x0ffdd01c in dlclose_doit (handle=handle@entry=0x100141a0) at
dlclose.c:35
#5 0xf7a9b50c in _dl_catch_error (objname=0x1001409c,
errstring=0x100140a0,
mallocedp=0x10014098, operate=0xffdcfec <dlclose_doit>,
args=0x100141a0)
at dl-error.c:187
#6 0x0ffdd74c in _dlerror_run (operate=0xffdcfec <dlclose_doit>,
args=args@entry=0x100141a0) at dlerror.c:163
#7 0x0ffdd06c in __dlclose (handle=handle@entry=0x100141a0) at
dlclose.c:46
#8 0x1000186c in do_test () at tst-tls7.c:108
#9 0x100011a8 in main (argc=<optimized out>, argv=<optimized out>)
at ../test-skeleton.c:279
All the others are somewhere within malloc or free called from spin.
--
Joseph S. Myers
joseph@codesourcery.com