From owner-freebsd-hackers Wed Feb 18 08:22:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA06462 for freebsd-hackers-outgoing; Wed, 18 Feb 1998 08:22:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA06347 for ; Wed, 18 Feb 1998 08:21:35 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id QAA04844; Wed, 18 Feb 1998 16:20:17 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id RAA02048; Wed, 18 Feb 1998 17:20:16 +0100 (MET) Message-ID: <19980218172015.22080@follo.net> Date: Wed, 18 Feb 1998 17:20:15 +0100 From: Eivind Eklund To: Mike Smith Cc: hackers@FreeBSD.ORG Subject: Re: ed overwrite clue? References: <19980218002852.55010@follo.net> <199802180017.QAA03678@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199802180017.QAA03678@dingo.cdrom.com>; from Mike Smith on Tue, Feb 17, 1998 at 04:17:47PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 17, 1998 at 04:17:47PM -0800, Mike Smith wrote: > > > > I'm about to start trigging some crashdumps on purpose now, so I can > > > > get a good look at how a dump for an OK case is. > > > > > > Do you have any custom code in the kernel? > > > > Yes. And the system won't boot without it, so ripping it out is > > really not an option. I could try to revert as much as possible, but > > it really doesn't look like any of the code that is revertible is at > > fault; almost none of it has been excersised yet. > > The only reason I asked was inre: stack overflow. Interesting new data point - this diff segment @@ -2616,7 +2661,9 @@ void edintr(unit) int unit; { + if ((unsigned long)&unit == 0xefbfffd8) + return; edintr_sc (&ed_softc[unit]); } almost completely stopped the errors. The crashes usually happen at a fixed stack offset; after adding this patch it seemed to be between 100x and 1000x harder to crash. (I've only run two test-runs so far; I've started another, but now it takes time to provoke a crash). The new crashes would have been blocked by a compare against 0xefbfffcc; I'm going to try to add this, and see if there are even more layers here. The above patch is not a solution; each time it triggers, it blocks all incoming data until another outgoing packet has been sent. It is just an interesting point. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message