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: Torvald Riegel <triegel at redhat dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Ilya Palachev <i dot palachev at samsung dot com>, libc-alpha at sourceware dot org, nd at arm dot com
- Date: Thu, 21 Jan 2016 21:58:19 +0100
- Subject: Re: [PATCH][BZ #19329] Fix race between tls allocation at thread creation and dlopen
- Authentication-results: sourceware.org; auth=none
- References: <568D5E11 dot 3010301 at arm dot com> <5693CEC1 dot 5080006 at samsung dot com> <5693DB7D dot 2040302 at arm dot com>
On Mon, 2016-01-11 at 16:42 +0000, Szabolcs Nagy wrote:
> On 11/01/16 15:48, Ilya Palachev wrote:
> > 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.
But that's no sufficient reason to remove the assertion. The assertion
might have very well been the intent of the programmer, and what the
code actually does might have not been what was intended. Removing the
assertion would be similar to removing documentation or comments just
because the code doesn't match it.
IMO, the proper way to solve this is to investigate the conflict, and
find out what the intent should be (eg, to make this work correctly);
after that, one knows whether the code or the assertion are wrong.
(If we are reasonably confident that the assertion might be wrong, or
that the damage caused by it failing is larger than an error triggered
by the potential bug, we might just make it not fail. But in this case,
the assertion should remain as a comment with a big FIXME or such next
to it.)