This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #19329] Fix race between tls allocation at thread creation and dlopen
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Ilya Palachev <i dot palachev at samsung dot com>, <libc-alpha at sourceware dot org>
- Cc: <nd at arm dot com>
- Date: Mon, 11 Jan 2016 16:42:37 +0000
- Subject: Re: [PATCH][BZ #19329] Fix race between tls allocation at thread creation and dlopen
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <568D5E11 dot 3010301 at arm dot com> <5693CEC1 dot 5080006 at samsung dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 11/01/16 15:48, Ilya Palachev wrote:
On 06.01.2016 21:33, Szabolcs Nagy wrote:
/* Keep track of the maximum generation number. This might
not be the generation counter. */
- assert (listp->slotinfo[cnt].gen <= GL(dl_tls_generation));
- maxgen = MAX (maxgen, listp->slotinfo[cnt].gen);
+ maxgen = MAX (maxgen, gen);
Thanks for the patch.
But it seems quite strange that the failed assertion is simply deleted from the code.
Is it still failing for your patch?
yes
How can you prove that it is working if the assertion that was failing is now just deleted from the code?
i can only prove that the assertion is wrong by
analysing the code: the condition it verifies
cannot be enforced with the current design.
removing it is harmless since the slotinfo entries
are lazy initialized.
If I just remove the assertion and do nothing else, the error will go away.
that's not enough: the dtv of the thread will be
in an inconsistent state and tls access in the
thread may crash.
Can you stay the assertion at its place or otherwise explain why do you want to remove it?
--
Best regards,
Ilya Palachev