From owner-freebsd-hackers@freebsd.org Tue Apr 20 07:40:53 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6474E5E8FAA for ; Tue, 20 Apr 2021 07:40:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FPbFw1rvzz3v8r for ; Tue, 20 Apr 2021 07:40:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 13K7eYTU082351 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 20 Apr 2021 10:40:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 13K7eYTU082351 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 13K7eXpR082350; Tue, 20 Apr 2021 10:40:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 20 Apr 2021 10:40:33 +0300 From: Konstantin Belousov To: Johannes Totz Cc: freebsd-hackers@freebsd.org Subject: Re: Debugging signal 11 Message-ID: References: <9d3b5c0cc7051f410fd04ff9ffba8aa0b5b32167.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4FPbFw1rvzz3v8r X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-0.99 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 07:40:53 -0000 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 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=, > dummy2=, dummy3=, dummy4=) > at /usr/src/sys/ddb/db_command.c:574 > #3 0xffffffff804d6dcf in db_command (last_cmdp=, > cmd_table=, 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=, code= 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 > #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.