Debugging ld.so in gdb

[Jacob Kroon]

On 2/4/22 15:22, Florian Weimer wrote:
> * Jacob Kroon:
> 
>> This is what I get, following the instructions above:
>>
>>> 171966	   0x00007ffff7fd85a0 <dfs_traversal+80>:	mov    0x0(%r13),%rax
>>> 171967	   0x00007ffff7fd85a4 <dfs_traversal+84>:	lea    -0x8(%rax),%rdx
>>> 171968	   0x00007ffff7fd85a8 <dfs_traversal+88>:	mov    %rdx,0x0(%r13)
>>> 171969	   0x00007ffff7fd85ac <dfs_traversal+92>:	mov    %rbp,-0x8(%rax)
>>> 171970	   0x00007ffff7fd85b0 <dfs_traversal+96>:	add    $0x8,%rsp
>>> 171971	   0x00007ffff7fd85b4 <dfs_traversal+100>:	pop    %rbx
>>> 171972	   0x00007ffff7fd85b5 <dfs_traversal+101>:	pop    %rbp
>>> 171973	   0x00007ffff7fd85b6 <dfs_traversal+102>:	pop    %r12
>>> 171974	   0x00007ffff7fd85b8 <dfs_traversal+104>:	pop    %r13
>>> 171975	   0x00007ffff7fd85ba <dfs_traversal+106>:	ret    
>>
>> Does that make sense ? Any other information I can provide. This is with
>> glibc-2.34-24.fc35.x86_64, Fedora 35.
> 
> This doesn't really make sense.  There's probably some GDB option to get
> a longer trace.
> 
> If it is crashing at the RET, it means that either code has been mapped
> over, or the stack has been corrupted.  At the crash site, what does
> 
>   print *(void**)$rsp
> 
> print?
> 
>   disassemble *(void**)$rsp
> 
> could also be interesting.
> 
> Thanks,
> Florian
> 

I put a breakpoint in "dfs_traversal" and each time I stop in there the
backtrace looks ok, but once the crash has happened, "bt" shows:

> #0  0x00007ffff7fad590 in ?? ()
> #1  0x00007ffff7d31b70 in ?? ()
> #2  0x00007ffff7d32830 in ?? ()
> #3  0x00007ffff7fae150 in ?? ()
> #4  0x00007ffff7fae730 in ?? ()
> #5  0x00007ffff7d32160 in ?? ()
> #6  0x00007ffff7952d30 in ?? ()
> #7  0x00007ffff79d1920 in ?? ()
> #8  0x00007ffff7d31000 in ?? ()
> #9  0x00007ffff79d1ef0 in ?? ()
> #10 0x00007ffff79d24c0 in ?? ()
> #11 0x00007ffff7952000 in ?? ()
> #12 0x00007ffff7952660 in ?? ()
> #13 0x00007ffff79537a0 in ?? ()
> #14 0x00007ffff7d31570 in ?? ()
> #15 0x00007ffff7ffda30 in _rtld_local ()
> #16 0x0000000000000001 in ?? ()
> #17 0xffffffffa5c00000 in ?? ()
> #18 0xffffeffc0b0e0000 in ?? ()
> #19 0x00007ffff795a409 in ?? ()
> #20 0x0000000000000000 in ?? ()

so maybe the stack gets corrupted..

Jacob