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.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2429 invoked from network); 14 Feb 2021 14:51:20 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 14 Feb 2021 14:51:20 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 1ess; Sun Feb 14 09:43:17 -0500 2021 Message-ID: <91D3FF1D1C092D773820E38BA6D98CEF@felloff.net> Date: Sun, 14 Feb 2021 15:43:06 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: leveraged non-blocking SOAP map/reduce information-scale self-signing solution Subject: Re: [9front] vac crash in libthread threadexitsall() Reply-To: 9front@9front.org Precedence: bulk you need to take a look at the memory image. obviously, p is nil or garbage (you havnet told us the address it faults on), but this should not happen. it is most likely that a memory corruption has broken the Proc* structures or at least the next pointer in one of the proc's or the global _threadpq. is there a way to reproduce it? maybe you can make a memory snapshot if the process with snap(4) when it happens again. -- cinap