Date: Tue, 20 Apr 2021 10:40:33 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Johannes Totz <johannes@jo-t.de> Cc: freebsd-hackers@freebsd.org Subject: Re: Debugging signal 11 Message-ID: <YH6FcWv6vPSb/ZRj@kib.kiev.ua> In-Reply-To: <s5l8mu$8rq$1@ciao.gmane.io> References: <9d3b5c0cc7051f410fd04ff9ffba8aa0b5b32167.camel@freebsd.org> <D25406A0-FBDB-48FA-94B2-0367A0527797@gmail.com> <s5l8mu$8rq$1@ciao.gmane.io>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 20, 2021 at 01:53:44AM +0100, Johannes Totz wrote:
> 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...
>
There is a tunable/sysctl machdep.uprintf_signal which makes kernel print
some information on trap, either on console or ctty. At least, it will
give you the $pc at the time of crash.
Intent of the functionality is exactly to get some data from trap when
debugger cannot be attached.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YH6FcWv6vPSb/ZRj>