From owner-freebsd-hackers@freebsd.org Tue Apr 20 00:54:05 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 7EA165DD498 for ; Tue, 20 Apr 2021 00:54:05 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane-mx.org) Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FPQDX3Ynbz3Jvr for ; Tue, 20 Apr 2021 00:54:04 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane-mx.org) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lYeeJ-0002UB-TN for freebsd-hackers@freebsd.org; Tue, 20 Apr 2021 02:53:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Johannes Totz Subject: Re: Debugging signal 11 Date: Tue, 20 Apr 2021 01:53:44 +0100 Message-ID: References: <9d3b5c0cc7051f410fd04ff9ffba8aa0b5b32167.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 In-Reply-To: Content-Language: en-GB X-Rspamd-Queue-Id: 4FPQDX3Ynbz3Jvr X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=jo-t.de (policy=none); spf=pass (mx1.freebsd.org: domain of freebsd-hackers@m.gmane-mx.org designates 116.202.254.214 as permitted sender) smtp.mailfrom=freebsd-hackers@m.gmane-mx.org X-Spamd-Result: default: False [0.10 / 15.00]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[jo-t.de : SPF not aligned (relaxed), No valid DKIM,none]; RBL_SENDERSCORE_FAIL(0.00)[116.202.254.214:server fail]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[116.202.254.214:from]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[116.202.254.214:from:127.0.2.255]; RCVD_TLS_LAST(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FORGED_SENDER(0.30)[johannes@jo-t.de,freebsd-hackers@m.gmane-mx.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:116.202.0.0/16, country:DE]; FROM_NEQ_ENVFROM(0.00)[johannes@jo-t.de,freebsd-hackers@m.gmane-mx.org]; 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 00:54:05 -0000 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=) 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...