This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][BZ #19329] Fix race between tls allocation at thread creation and dlopen


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.)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]