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

[Jonny Grant <jg@jguk.org>]

On 22/08/2022 07:41, Florian Weimer wrote:
> * Jonny Grant:
> 
>> Hello
>> I have a core file from a crash in glibc's ld.so
>>
>> Couldn't reproduce it. Was just wondering if there was any useful info
>> I could extract to identify which function it crashed in?
> 
>> I can see the backtrace using 'bt' command.
>> I can see the assembly using 'layout asm'
>>
>>
>> Core was generated by `/lib64/ld-linux-x86-64.so.2 /usr/lib/vmware/lib/libvmware-modconfig.so/libvmwar'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  0x00007fac33ccb540 in ?? ()
>> (gdb) bt
>> #0  0x00007fac33ccb540 in  ()
>> #1  0x00007fac33ccea00 in  ()
>> #2  0x00007fac33ccdfa0 in  ()
>> #3  0x00007fac33c496b0 in  ()
>> #4  0x00007fac33c49bf0 in  ()
>> #5  0x00007fac33c4a130 in  ()
>> #6  0x00007fac33ccd000 in  ()
>> #7  0x00007fac33c4a670 in  ()
>> #8  0x00007fac31cdf310 in  () at /usr/lib/vmware/lib/libvmwarebase.so/libvmwarebase.so
>>
>>
>> installing libc6-amd64-dbgsym doesn't show any more
> 
> Sometimes it's possible to get better backtraces by loading the symbol
> table for the name program using “file”, running ld.so and the program
> under the debugger, or both.  I've got a request open with our GDB
> developers to improve debugging with an explicit ld.so invocation, but
> so far, it's a known issue.
> 
> Thanks,
> Florian
> 


Hi Florian

Thank you for your reply with suggestion.

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?

Kind regards
Jonny