Re: Debugging ld.so in gdb

[Jacob Kroon <jacob.kroon@gmail.com>]

On 2/7/22 17:28, Florian Weimer wrote:
> * Florian Weimer:
> 
>> * Jacob Kroon:
>>
>>> I managed to build glibc master, and yes it also crashes. Reverting the
>>> suspicious commit:
>>>
>>> commit 15a0c5730d1d5aeb95f50c9ec7470640084feae8
>>> Author: Chung-Lin Tang <cltang@codesourcery.com>
>>> Date:   Thu Oct 21 21:41:22 2021 +0800
>>>
>>>     elf: Fix slow DSO sorting behavior in dynamic loader (BZ #17645)
>>>
>>> fixes the crash. Adding a couple of more people.
>>
>> Sorry, that is completely expected because this is where the faulty code
>> was added.
>>
>> I plan to stare at _dl_map_object_deps a bit, to figure out where the
>> discrepancy between l_initfini for the main program and the loaded
>> objects comes from.
> 
> I can see that we do not add l_fake objects (that failed to load) to the
> main search list (and nlist is not incremented).  But we do not remove
> them from the individual list of dependencies, leading to this
> discrepancy.
> 
> This would be consistent with this bug report:
> 
>   Dynamic loader DFS algorithm segfaults on missing libraries
>   <https://sourceware.org/bugzilla/show_bug.cgi?id=28868>
> 
> If you run with GLIBC_TUNABLES=glibc.rtld.dynamic_sort=0, do you see
> “not found” lines in the ldd output?
> 

I assume you meant "glibc.rtld.dynamic_sort=1", and not
"glibc.rtld.dynamic_sort=0", since that also crashes. With "1" I see no
crash, and three entries of "libjvm.so => not found".

> If yes, do these surprising libjvm.so objects have l_fake set in their
> link map?
> 

Yes, looking at the "libjvm.so" entries in rpo[] right before the crash,
I see l_faked == 1 for all three, and *only* for those three.

Jacob