This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: nptl/tst-stack4 failure
On 16/11/16 16:48, Florian Weimer wrote:
> 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.
>
nptl/tst-stack4 is failing for me for a long time (but not reliably)
i have a patch for it, but haven't finished the concurrency notes:
https://sourceware.org/bugzilla/show_bug.cgi?id=19329