nptl/tst-stack4 failure
Florian Weimer
fweimer@redhat.com
Wed Nov 16 16:48:00 GMT 2016
On 11/16/2016 04:52 PM, Siddhesh Poyarekar wrote:
> On Wednesday 16 November 2016 09:09 PM, Florian Weimer wrote:
>> The nptl/tst-stack4 test fails reliably on several architectures for me
>> (ppc, ppc64, aarch64). I'm trying to figure out what's going on.
>
> I saw this yesterday and bisected it to this commit:
>
> =================
> commit 17af5da98cd2c9ec958421ae2108f877e0945451
> Author: Alexandre Oliva <aoliva@redhat.com>
> Date: Wed Sep 21 22:01:16 2016 -0300
>
> [PR19826] fix non-LE TLS in static programs
Thanks, I was approaching this commit as well, I think.
> I had planned to look at it later in the week but if you have the time
> then please feel free to pick it up.
I'm not sure what's going on there. I don't know what the expectations
for this code are. Clearly, __tls_get_addr has to be async-signal-safe,
but it calls update_get_addr and tls_get_addr_tail, and the latter
acquires dl_load_lock.
There is an acquire load on dl_tls_max_dtv_idx in dl-tls.c, but it's
never written in an atomic fashion. It seems that nptl/allocatestack.c
calls into the elf/dl-tls.c code without acquiring any rtld locks.
Considering that we reuse modid slots after a dlclose, this can't be
right, I think.
Florian
More information about the Libc-alpha
mailing list