Debugging signal 11

[Johannes Totz]

On 18/04/2021 21:06, Lucas Nali de Magalhães wrote:
> On Apr 18, 2021, at 4:18 PM, Ian Lepore <ian at 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...