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: Status of build bots?


* Zack Weinberg:

> On 8/22/19 8:43 AM, Florian Weimer wrote:
>> Thanks, found it.  It's the file identity data in l_file_id for the main
>> map, yet another difference between kernel loading of the executable and
>> late loading after an explicit loader invocation.
>> 
>> Unfortunately, after fixing this, the test case fails for PIE
>> executables with the original assert:
>> 
>> Inconsistency detected by ld.so: ../elf/dl-tls.c: 517: _dl_allocate_tls_init: Assertion `listp != NULL' failed!
>> 
>> Thus the fix for bug 16634 was incorrect. 8-(
>> 
>> This failure reproduces out-of-tree, without an explicit loader
>> invocation, so it is real.  We just did not have test coverage for this
>> case before.
>> 
>> On the positive side, all this work on the test wasn't for nothing.  But
>> it means that I cannot get the test to pass on PIE-by-default toolchains
>> easily.
>
> Suggestion: duplicate this test, compile one copy with explicit -pie
> and one with explicit -no-pie, and xfail the -pie version.  That
> avoids having testing depend on the configuration of the build
> toolchain, gets us back to green buildbots quicker, and we can worry
> about fixing 16634 properly when someone actually has time to do that.

We have a partner bug report about this, so it's likely I have to fix
this properly anyway.

My hunch is that the assert can also happen if dlopen fails much, much
later, in relocation processing, and that could be the actually relevant
case (I don't know that yet, I need to write a different glibc test for
that).

Thanks,
Florian


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