Re: Debugging ld.so in gdb
Jacob Kroon via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> >>> 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