tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Examining core dump with gdb



> On Mar 14, 2025, at 11:56 AM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> 
>>> When I try with unzipped core dump:
>>> /var/crash#gdb
>>> (gdb) target kvm netbsd.10.core
>>> [1]   Abort trap (core dumped) gdb
>>> /var/crash#
> 
>> That should not die like this :-(
> 
> Indeed.  I'm reminded of something I saw years ago in the gcc docs,
> saying that if the compiler gets a fatal signal for any input
> whatsoever, that is a bug.  Similar remarks apply - or at least IMO
> should - to debuggers.
> 
>> But the problem is that you did not supply a kernel executable. For
>> best results you want a kernel with symbols (netbsd.gdb) but a
>> regular kernel will work:
> 
>> /var/crash#gdb netbsd
>> (gdb) target kvm netbsd.10.core
> 
> One caution here: on some versions, under circumstances I have not put
> in the effort to fully understand, I've had savecore write a
> zero-length file for the kernel.  You might have to use /netbsd (or
> wherever you keep your kernel) instead.

I recently learned that if you do

# cd /var/crash
# gdb netbsd.10
(gdb) target kvm netbsd.10.core

then the backtrace won't have as much information as if you do

# cd /var/crash
# gdb /netbsd # where /netbsd was copied from the netbsd.gdb file
(gdb) target kvm netbsd.10.core

even though you may think that /var/crash/netbsd.10 ought to contain
the same information as /netbsd. So maybe it would be a good idea
to run "gdb /netbsd" even when not taking into account a potential
zero-length /var/crash/netbsd.10.


> /~\ The ASCII				  Mouse
> \ / Ribbon Campaign
> X  Against HTML		mouse%rodents-montreal.org@localhost
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B



Home | Main Index | Thread Index | Old Index