From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <2f8e0f32e814c7198926c7687a719d73@plan9.bell-labs.com> From: "Russ Cox" To: 9fans@cse.psu.edu Subject: Re: [9fans] more fossil woes In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Mon, 10 Nov 2003 23:59:06 -0500 Topicbox-Message-UUID: 868c45dc-eacc-11e9-9e20-41e7f4b1d025 > assert failed: b->nlock == 1 > fossil 44: suicide: sys: trap: fault read addr=0x0 pc=0x0002b6b7 I believe I have just fixed this bug. Jmk caught one and held it down for me. Sources are there now, binary tomorrow. > It was the first crash in a long time, but unfortunately I had no way of > finding out who/what had caused it, because Plan 9 does not allow me to > examine process' activity based on utilization of a particular resource. I don't understand what you mean here. What query would you have asked the system to help isolate the problem? I needed to use acid to look around at the various fossil processes involved in causing the crash. Given that your fossil was gone, I have a hard time believing acid would have run. And I can't imagine any general questions the system might answer that would have helped. > (Interestingly enough, when I suggested such "features" are added to the > system there was an outrage, especially from people who never use Plan 9, > telling me I'm just polluting the beautiful system :)... And I definitely don't understand what you mean here. I have all sorts of trippy acid to look at who is using what. If you identified an interesting set of questions that could be answered by exporting some kernel information in a new format, I would be all ears. Russ