Re: ld-linux-x86-64 core file SIGSEGV

[Jonny Grant <jg@jguk.org>]

On 22/08/2022 11:52, Florian Weimer wrote:
> * Jonny Grant:
> 
>> On 22/08/2022 11:43, Florian Weimer wrote:
>>> * Jonny Grant:
>>>
>>>> I got it to load the debug symbol using "file" command you
>>>> mentioned. Unfortunately backtrace still empty.  The debug symbols
>>>> /usr/lib/debug/.build-id/61/ef896a699bb1c2e4e231642b2e1688b2f1a61e.debug
>>>> are only 592,952 bytes
>>>>
>>>> I would probably just prefer if binaries weren't separated from their
>>>> debug symbols. Do you know any distributions that don't strip symbols
>>>> from glibc?
>>>
>>> I'm not sure if this is caused by debuginfo separation.  I run into GDB
>>> when I use my own custom-built glibc with unstripped debuginfo.
>>>
>>> Anyway, you can probably use eu-unstrip from elfutils to undo the
>>> debuginfo separation.
>>>
>>> Thanks,
>>> Florian
>>
>> That's a good tip than you.
>>
>> I did use objdump -d on the ld.so, but couldn't spot anything similar
>> to what I saw in "layout asm" from gdb.
> 
> In my experience, the missing symbols are usually from the main program,
> and then the stack backtrace runs off the rails pretty quickly
> (resulting in garbage addresses).
> 
>> Is it ever possible to match up disassembly with the gdb core
>> disassembly this way?
> 
> You cloud get the object addresses from /proc/PID/mem, compute the
> relative offset, and then use addr2line or objdump to find out more.
> 
> Thanks,
> Florian
> 

Thank you for the extra information. I will try to find a way to reproduce it, maybe that's clearer. 
Thanks, Jonny