public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
* ld-linux-x86-64 core file SIGSEGV
@ 2022-08-20 23:37 Jonny Grant
  2022-08-22  6:41 ` Florian Weimer
  0 siblings, 1 reply; 7+ messages in thread
From: Jonny Grant @ 2022-08-20 23:37 UTC (permalink / raw)
  To: libc-help

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


I'm running latest Ubuntu LTS. Just thought I would take a look, see if there is an issue.

$ /lib64/ld-linux-x86-64.so.2 --version
ld.so (Ubuntu GLIBC 2.35-0ubuntu3.1) stable release version 2.35.
Copyright (C) 2022 Free Software Foundation, Inc.


Cheers, Jonny

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: ld-linux-x86-64 core file SIGSEGV
  2022-08-20 23:37 ld-linux-x86-64 core file SIGSEGV Jonny Grant
@ 2022-08-22  6:41 ` Florian Weimer
  2022-08-22 10:26   ` Jonny Grant
  0 siblings, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2022-08-22  6:41 UTC (permalink / raw)
  To: Jonny Grant; +Cc: libc-help

* 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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: ld-linux-x86-64 core file SIGSEGV
  2022-08-22  6:41 ` Florian Weimer
@ 2022-08-22 10:26   ` Jonny Grant
  2022-08-22 10:43     ` Florian Weimer
  0 siblings, 1 reply; 7+ messages in thread
From: Jonny Grant @ 2022-08-22 10:26 UTC (permalink / raw)
  To: Florian Weimer; +Cc: libc-help



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
 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: ld-linux-x86-64 core file SIGSEGV
  2022-08-22 10:26   ` Jonny Grant
@ 2022-08-22 10:43     ` Florian Weimer
  2022-08-22 10:47       ` Jonny Grant
  0 siblings, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2022-08-22 10:43 UTC (permalink / raw)
  To: Jonny Grant; +Cc: libc-help

* 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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: ld-linux-x86-64 core file SIGSEGV
  2022-08-22 10:43     ` Florian Weimer
@ 2022-08-22 10:47       ` Jonny Grant
  2022-08-22 10:52         ` Florian Weimer
  0 siblings, 1 reply; 7+ messages in thread
From: Jonny Grant @ 2022-08-22 10:47 UTC (permalink / raw)
  To: Florian Weimer; +Cc: libc-help



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.

Is it ever possible to match up disassembly with the gdb core disassembly this way?
Cheers, Jonny

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: ld-linux-x86-64 core file SIGSEGV
  2022-08-22 10:47       ` Jonny Grant
@ 2022-08-22 10:52         ` Florian Weimer
  2022-08-22 16:29           ` Jonny Grant
  0 siblings, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2022-08-22 10:52 UTC (permalink / raw)
  To: Jonny Grant; +Cc: libc-help

* 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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: ld-linux-x86-64 core file SIGSEGV
  2022-08-22 10:52         ` Florian Weimer
@ 2022-08-22 16:29           ` Jonny Grant
  0 siblings, 0 replies; 7+ messages in thread
From: Jonny Grant @ 2022-08-22 16:29 UTC (permalink / raw)
  To: Florian Weimer; +Cc: libc-help



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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-08-22 16:29 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-20 23:37 ld-linux-x86-64 core file SIGSEGV Jonny Grant
2022-08-22  6:41 ` Florian Weimer
2022-08-22 10:26   ` Jonny Grant
2022-08-22 10:43     ` Florian Weimer
2022-08-22 10:47       ` Jonny Grant
2022-08-22 10:52         ` Florian Weimer
2022-08-22 16:29           ` Jonny Grant

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).