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.8 required=5.0 tests=DATE_IN_PAST_12_24
	autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 4208 invoked from network); 30 Jan 2021 04:45:05 -0000
Received: from 1ess.inri.net (216.126.196.35)
  by inbox.vuxu.org with ESMTPUTF8; 30 Jan 2021 04:45:05 -0000
Received: from duke.felloff.net ([216.126.196.34]) by 1ess; Fri Jan 29 08:42:10 -0500 2021
Message-ID: <6E1A501481850A7829B9B9DF58041B3C@felloff.net>
Date: Fri, 29 Jan 2021 14:41:59 +0100
From: cinap_lenrek@felloff.net
To: 9front@9front.org
In-Reply-To: <4E3B69E98B663791E1EAB73ACDBDE6CA@hera.eonet.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: anonymous NoSQL session reduce/map framework 
Subject: Re: [9front] acid:V: line in mkfile for pc64
Reply-To: 9front@9front.org
Precedence: bulk

hey kenji!

is it possible for you to make a picture of the crash?

with ktrace -i we can get a better backtrace. as the
places you put do not make much sense. but this is
normal as the kernel just prints every stack location
that looks like a pointer into the kernel text. it
might actually just be left over data in uninitialized
variables from previous call chains.

ktrace knows the call frame sizes from the debug symbols,
and skips the false text addresses. with the -i flag,
it will interactively ask you for the stack locations
of the next return pc.

--
cinap