Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 18 Apr 2021 15:53:37 -0300
From:      =?utf-8?Q?Lucas_Nali_de_Magalh=C3=A3es?= <rollingbits@gmail.com>
To:        freebsd-hackers@freebsd.org
Subject:   Re: Debugging signal 11
Message-ID:  <4AF3D639-FB07-46B5-9058-114576BD4EDB@gmail.com>
In-Reply-To: <s5d7t6$bdl$1@ciao.gmane.io>
References:  <s5d7t6$bdl$1@ciao.gmane.io>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi.

There are a few problems after the end of your email. I inlined them.

> On Apr 16, 2021, at 8:51 PM, Johannes Totz <johannes@jo-t.de> wrote:
> My init(8) is crashing with a signal 11.

Crossing with the end, init is the mother of all processes. A longer
explanation is in the man page you cited, even. An explanation of signal 11
can be found by googling it and also in
https://www.cyberciti.biz/tips/segmentation-fault-on-linux-unix.html a text
I found googling. Short story: init is well tested, so it must be hardware f=
ault.

> I've added a breakpoint() in kern_sig.c:
>=20
> static int
> issignal(struct thread *td)
> {
>    // [snip]
>=20
>    case (intptr_t)SIG_DFL:
>        /*
>         * Don't take default actions on system processes.
>         */
>        if (p->p_pid <=3D 1) {
> #ifdef DIAGNOSTIC
>            /*
>             * Are you sure you want to ignore SIGSEGV
>             * in init? XXX
>             */
>            printf("Process (pid %lu) got signal %d\n",
>                (u_long)p->p_pid, sig);
>=20
>            breakpoint();    // added by me
> #endif
>            break;        /* =3D=3D ignore */
>        }
>=20
>    // [snip]
> }
>=20
> That breaks to DDB where I can call dump. So far so good.

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.

> But how do I get back to the stack(trace) and instruction that caused the s=
egv? Either in DDB or KGDB?

"bt" is a shortcut for "backtrace" and is the command to get a stack trace
in gdb. BTW, "attach" and "bt" are two of the most basic debugger commands.

--=20
rollingbits =E2=80=94 =F0=9F=93=A7 rollingbits@icloud.com =F0=9F=93=A7 rolli=
ngbits@gmail.com =F0=9F=93=A7 rollingbits@yahoo.com =F0=9F=93=A7 rollingbits=
@terra.com.br =F0=9F=93=A7 rollingbits@globo.com=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AF3D639-FB07-46B5-9058-114576BD4EDB>