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: Thu, 9 Jan 2014 15:46: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> <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> <CALoOobOHjd+8guXBEsHuO=FtiPFRED4Zb=qDdTvEHr=01nRwHg at mail dot gmail dot com>
On Wed, 8 Jan 2014, Paul Pluzhnikov wrote:
> 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?
$1 = {l_addr = 266268672,
l_name = 0x100140a8
"/scratch/jmyers/eglibc/p/obj/glibc-4.7-0-powerpc-linux-gnu-i686-pc-linux-gnu/default/nptl/tst-tls7mod.so",
l_ld = 0xfdfff04,
l_next = 0x0, l_prev = 0xf7abe530 <_rtld_local+1304>, l_real =
0x100141a0,
l_ns = 0, l_libname = 0x100143fc, l_info = {0x0, 0xfdfff14, 0xfdfff64,
0xfdfff5c, 0xfdfff2c, 0xfdfff3c, 0xfdfff44, 0xfdfff84, 0xfdfff8c,
0xfdfff94, 0xfdfff4c, 0xfdfff54, 0xfdfff1c, 0xfdfff24, 0x0, 0x0, 0x0,
0x0,
0x0, 0x0, 0xfdfff6c, 0x0, 0x0, 0xfdfff74, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0,
0x0, 0x0, 0x0, 0x0, 0xfdfff7c, 0xfdfffa4, 0xfdfff9c, 0x0, 0x0, 0x0,
0x0,
0xfdfffb4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xfdfffac,
0x0 <repeats 25 times>, 0xfdfff34}, l_phdr = 0xfdef034,
l_entry = 266270112, l_phnum = 7, l_ldnum = 28, l_searchlist = {
r_list = 0x100144a4, r_nlist = 4}, l_symbolic_searchlist = {
r_list = 0x100143f8, r_nlist = 0}, l_loader = 0x0,
l_versions = 0x10014008, l_nversions = 7, l_nbuckets = 3,
l_gnu_bitmask_idxbits = 1, l_gnu_shift = 6, l_gnu_bitmask = 0xfdef144, {
l_gnu_buckets = 0xfdef14c, l_chain = 0xfdef14c}, {
l_gnu_chain_zero = 0xfdef128, l_buckets = 0xfdef128},
l_direct_opencount = 0, l_type = lt_loaded, l_relocated = 1,
l_init_called = 1, l_global = 0, l_reserved = 0, l_phdr_allocated = 0,
l_soname_added = 0, l_faked = 0, l_need_tls_init = 0, l_auditing = 0,
l_audit_any_plt = 0, l_removed = 1, l_contiguous = 1,
l_symbolic_in_local_scope = 0, l_free_initfini = 1, l_rpath_dirs = {
dirs = 0x0, malloced = 0}, l_reloc_result = 0x0, l_versyms =
0xfdef394,
l_origin = 0x10014420
"/scratch/jmyers/eglibc/p/obj/glibc-4.7-0-powerpc-linux-gnu-i686-pc-linux-gnu/default/nptl",
l_map_start = 266268672,
l_map_end = 266338340, l_text_end = 266272768, l_scope_mem =
{0xf7abea68,
0x10014300, 0x0, 0x0}, l_scope_max = 4, l_scope = 0x1001435c,
l_local_scope = {0x10014300, 0x0}, l_dev = 21, l_ino = 37115417,
l_runpath_dirs = {dirs = 0x0, malloced = 0}, l_initfini = 0x10014490,
l_reldeps = 0x0, l_reldepsmax = 0, l_used = 1, l_feature_1 = 0,
l_flags_1 = 0, l_flags = 0, l_idx = 6, l_mach = {<No data fields>},
l_lookup_cache = {sym = 0xfdef1e0, type_class = 0, value = 0x0, ret =
0x0},
l_tls_initimage = 0xfdffeb8, l_tls_initimage_size = 4, l_tls_blocksize =
4,
l_tls_align = 4, l_tls_firstbyte_offset = 0, l_tls_offset = -2,
l_tls_modid = 2, l_tls_dtor_count = 0, l_relro_addr = 69304,
l_relro_size = 328, l_serial = 6, l_audit = 0x100143f8}
--
Joseph S. Myers
joseph@codesourcery.com