Date: Tue, 20 Apr 2021 01:53:44 +0100 From: Johannes Totz <johannes@jo-t.de> To: freebsd-hackers@freebsd.org Subject: Re: Debugging signal 11 Message-ID: <s5l8mu$8rq$1@ciao.gmane.io> In-Reply-To: <D25406A0-FBDB-48FA-94B2-0367A0527797@gmail.com> References: <9d3b5c0cc7051f410fd04ff9ffba8aa0b5b32167.camel@freebsd.org> <D25406A0-FBDB-48FA-94B2-0367A0527797@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18/04/2021 21:06, Lucas Nali de Magalhães wrote:
> On Apr 18, 2021, at 4:18 PM, Ian Lepore <ian@freebsd.org> wrote:
>>
>> On Sun, 2021-04-18 at 15:53 -0300, Lucas Nali de Magalhães wrote:
>>> This also isn't the usual. Debugging a running process is possible but
>>> the process you used is the wrong one. Debugging init, OTOH, is a
>>> completely different story: init is the first process and is the most
>>> important process of any unix. The actual command varies from
>>> debugger to debugger but in gdb, "attach pid" may do the trick for
>>> you. You will need to be extra cautious because of you are aiming init.
>>> Ideally, init is the process supposed to catch the signals and keep
>>> the system running. So a break into it may cause your system to crash.
>>
>> Given that it is init that is segfaulting, how to you propose that the
>> OP lauch gdb in order to do an attach to init? In other words: there
>> is a reason the OP is trying to use the kernel debugger to examine
>> what's going on here.
>
> First the OP was able to modify init. Then it was asked the command
> to do a stack trace. Thus the OP clearly hasn't the full knowledge of
> the procedure and the risks. Besides this, kgdb is based on gdb. I
> thought they should know.
Hi Lucas and others,
thanks for responding.
I didn't modify init, I've been messing around in the kernel. And that
messing around makes init crash, so totally my own fault. But I would
have liked it to work instead, thusly trying to debug why the crash happens.
bt in kgdb gives me (beware of line break):
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(offsetof(struct pcpu,
(kgdb) bt
#0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xffffffff804d700a in db_dump (dummy=<optimized out>,
dummy2=<unavailable>, dummy3=<unavailable>, dummy4=<unavailable>)
at /usr/src/sys/ddb/db_command.c:574
#3 0xffffffff804d6dcf in db_command (last_cmdp=<optimized out>,
cmd_table=<optimized out>, dopager=1) at /usr/src/sys/ddb/db_command.c:481
#4 0xffffffff804d6b3d in db_command_loop () at
/usr/src/sys/ddb/db_command.c:534
#5 0xffffffff804d9fc8 in db_trap (type=<optimized out>, code=<optimized
out>) at /usr/src/sys/ddb/db_main.c:252
#6 0xffffffff80744106 in kdb_trap (type=3, code=0,
tf=0xfffffe0021c75a20) at /usr/src/sys/kern/subr_kdb.c:693
#7 0xffffffff809d64a1 in trap (frame=0xfffffe0021c75a20) at
/usr/src/sys/amd64/amd64/trap.c:583
#8 <signal handler called>
#9 0xffffffff806feb45 in issignal (td=0xfffff80002213740) at
/usr/src/sys/amd64/include/cpufunc.h:65
#10 cursig (td=0xfffff80002213740) at /usr/src/sys/kern/kern_sig.c:599
#11 0xffffffff8075a428 in ast (framep=0xfffffe0021c75c00) at
/usr/src/sys/kern/subr_trap.c:329
#12 0xffffffff809b2979 in doreti_ast () at
/usr/src/sys/amd64/amd64/exception.S:1150
#13 0x0000000000000000 in ?? ()
...which is the stacktrace of the fault handler, not the
instruction/function that caused the fault.
Select frame #11 and:
p *framep
and:
disassemble tf_rip
But that would have been too easy...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?s5l8mu$8rq$1>