Re: Debugging ld.so in gdb

[Florian Weimer <fweimer@redhat.com>]

* 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?

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

Thanks,
Florian