From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1838 invoked from network); 24 Sep 2023 15:18:30 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 24 Sep 2023 15:18:30 -0000 Received: from mx.sdf.org ([205.166.94.24]) by 9front; Sun Sep 24 11:13:17 -0400 2023 Received: from sdf.org (IDENT:dmadhatr@sverige.sdf.org [205.166.94.6]) by mx.sdf.org (8.16.1/8.14.5) with ESMTPS id 38OFDAnS018086 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO) for <9front@9front.org>; Sun, 24 Sep 2023 15:13:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sdf.org; s=sdf.org; t=1695568393; bh=lkTzVpohRbl1ZlMSuESt1721VhK0E4zOm/allb2bnB0=; h=Date:From:To:Subject:In-Reply-To:References; b=I7Q1/rI4Sd7SbyivdBoJ/A/Hdxa2skdZFdOIiNtYleSCAjCc4ppep3axLegmqe/UT Obot0aGJAJURaK6LDPShsPI5/x/vP3rKut4TMyzhzr3nXlr95QDoUaUBUfr2i1nc14 aHo6pMdUQbAUnHf3oCTHMWryYanzgzVyqfLMc9aA= Received: from localhost (dmadhatr@localhost) by sdf.org (8.16.1/8.12.8/Submit) with ESMTP id 38OFD9wR020398 for <9front@9front.org>; Sun, 24 Sep 2023 15:13:09 GMT Date: Sun, 24 Sep 2023 15:13:09 +0000 (UTC) From: Dmad To: 9front@9front.org In-Reply-To: Message-ID: <3606b921-b556-2f37-43e0-9dca18e3bc01@sdf.org> References: <8ea3b9d6-c797-179b-cf09-860ebbb4ade5@sdf.org> <5bd1f3ec-58ee-9618-fbfe-caefe906e1f4@sdf.org> <0e548cd8-4376-de24-6a78-000f0d98beb0@sdf.org> <931efd84-9713-5263-02ca-8dc5a93e8304@sdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: encrypted structured metadata database Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV Reply-To: 9front@9front.org Precedence: bulk On Sat, 23 Sep 2023, Amavect wrote: Was able to fix the memory issue with a tas.c function replacement yesterday, however, you may have found a way to fix the cpu bug message everyone has been getting from the 9front drawterm build. > Date: Sat, 23 Sep 2023 23:44:32 -0500 > From: Amavect > Reply-To: 9front@9front.org > To: 9front@9front.org > Subject: Re: [9front] 9Front Drawterm Code 139 Sig 11 SIGSEGV > > On Sat, Sep 23, 2023 at 6:24?PM Dmad wrote: >> #3 0x0000000000226cdf in incref (r=0x0) at chan.c:57 > You have a null pointer dereference. > > Digging into this a bit, > kern/chan.c:847: incref(&path->ref); > ref is the first member of path, and path is not dereferenced, > so the question is where c->path is set to null. > > A path of "./dev/label" results in namec()'s default case to be taken. > kern/chan.c:1222: c = up->dot; > > up->dot appears to be defined in _syschdir(). > We know that chdir failed, so something happened. > kern/sysfile:628: > validaddr(name, 1, 0); > c = namec(name, Atodir, 0, 0); > cclose(up->dot); > up->dot = c; > > Note that the validaddr() is a no-op macro on drawterm, > but an actual function on 9front. > If that would detect a problem, then maybe drawterm should have it. > Perhaps someone else has a better idea of kernel internals, > and how they parallel to drawterm. > >> Was not able to get a bt stack after compiling with additional CFLAGs > Clearly a crash didn't happen with -O0. > Were you able to login and start typing commands into drawterm? > > For fun, I installed FreeBSD on Qemu and compiled drawterm. > No issues logging onto my server, > but I don't know how to trigger a chdir failure. > > Thanks, > Amavect > > dmadhatr@sdf.org SDF Public Access UNIX System - http://sdf.org