Re: savecore: BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276

On 10/25/18 2:14 AM, Marcin Cieslak wrote:
> On Wed, 24 Oct 2018, John Baldwin wrote:
> 
>> On 10/23/18 10:58 AM, Marcin Cieslak wrote:
>>> This GDB was configured as "amd64-marcel-freebsd"...BFD: /boot/kernel/kernel: invalid relocation type 37
>>> BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276
>>>
>>> The kernel has been built on 11.1 with LD=/usr/bin/ld.lld
>>>
>>> Is this something that matters at all?
>>
>> It is not something that is likely to be fixed.  If you pkg install gdb from
>> ports, is the kgdb it includes able to examine the crash dump?
> 
> Not really (using 8.2 from ports):
> 
> # /usr/local/bin/kgdb82 -n 5 /usr/obj/usr/src/sys/GENERIC/kernel.debug
> GNU gdb (GDB) 8.2 [GDB v8.2 for FreeBSD]
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-portbld-freebsd11.1".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>     <http://www.gnu.org/software/gdb/documentation/>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/obj/usr/src/sys/GENERIC/kernel.debug...done.
> thread.c:93: internal-error: struct thread_info *inferior_thread(): Assertion `tp' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) 

This usually means the kernel image you are using doesn't match the vmcore, so
it's reading garbage data from the vmcore since the symbol offsets are wrong.

You can test this by doing what crashinfo does: compare the version string in the
/var/crash/info.5 file with 'p version' in kgdb (or gdb) of the kernel without
a vmcore.

-- 
John Baldwin