Re: Debugging ld.so in gdb

On 2/7/22 13:32, Jacob Kroon wrote:
> On 2/7/22 13:27, Florian Weimer wrote:
>> * Jacob Kroon:
>>
>>>> What I find really confusing is that this is not the result of a dlopen
>>>> call.  I definitely would expect that the maps array contains *all*
>>>> objects that are being loaded.  Clearly this is not the case here.
>>>> Somehow certain objects are missing, and then they get written into the
>>>> rpo array.
>>>>
>>>> Please try to find libjvm.so among the l_initfini arrays of the objects.
>>>
>>> I do find libjvm.so in a couple of the maps[]->l_initfini[]->l_name
>>> arrays, yes.
>>
>> Okay, and of course there is an assumption that those make it to the
>> maps.  No wonder we run off the array.
>>
>>>> It must be present somewhere.  I assume it's also on the main list,
>>>> which starts off at _rtld_global._dl_ns[0]._ns_loaded.
>>>
>>> Hmm how do I iterate over that data structure ?
>>>
>>> See below:
>>>> (gdb) print _rtld_global._dl_ns[0]._ns_loaded[0]->l_name
>>>> $186 = 0x7ffff7ff1d97 ""
>>>> (gdb) print _rtld_global._dl_ns[0]._ns_loaded[1]->l_name
>>>> $187 = 0x0
>>>> (gdb) print _rtld_global._dl_ns[0]._ns_loaded[2]->l_name
>>>> $188 = 0x0
>>>> (gdb) print _rtld_global._dl_ns[0]._ns_loaded->l_name
>>>> $189 = 0x7ffff7ff1d97 ""
>>>> (gdb) print _rtld_global._dl_ns[1]._ns_loaded->l_name
>>>> Cannot access memory at address 0x8
>>>> (gdb) print _rtld_global._dl_ns[2]._ns_loaded->l_name
>>>> Cannot access memory at address 0x8
>>
>> It's a list chained by l_prev/l_next.
>>
> 
> Ok, yes "libjvm.so" is there, in multiple entries.
> 

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.

Jacob