From owner-freebsd-current@FreeBSD.ORG Wed Aug 13 03:14:18 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02E6F37B401 for ; Wed, 13 Aug 2003 03:14:18 -0700 (PDT) Received: from sweeper.openet-telecom.com (mail.openet-telecom.com [62.17.151.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43E8D43F85 for ; Wed, 13 Aug 2003 03:14:16 -0700 (PDT) (envelope-from peter.edwards@openet-telecom.com) Received: from mail.openet-telecom.com (unverified) by sweeper.openet-telecom.com ; Wed, 13 Aug 2003 11:17:49 +0100 Received: from [10.0.0.40] (10.0.0.40) by mail.openet-telecom.com (NPlex 6.5.027) id 3F268E0000008B73; Wed, 13 Aug 2003 11:12:27 +0100 From: Peter Edwards To: Terry Lambert In-Reply-To: <3F39DCCF.DB0B9C78@mindspring.com> References: <20030811100549.GA33392@technokratis.com> <20030811130937.GA34564@technokratis.com> <3F38D515.2950D743@mindspring.com> <1060704284.45511.118.camel@rocklobster.openet-telecom.lan> <3F39DCCF.DB0B9C78@mindspring.com> Content-Type: text/plain Organization: Openet Telecom Message-Id: <1060769172.45511.257.camel@rocklobster.openet-telecom.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 13 Aug 2003 11:06:13 +0100 Content-Transfer-Encoding: 7bit cc: Bosko Milekic cc: current@freebsd.org Subject: Re: 5.1, Data Corruption, Intel, Oh my! [patch] - Fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2003 10:14:18 -0000 On Wed, 2003-08-13 at 07:38, Terry Lambert wrote: > Peter Edwards wrote: > > > ... He might also want to look for any function pointer > > > that takes 5 arguments; > > > > Nice tactic, but misleading in this case, methinks. > > > > I assume your basing this on the 5 arguments shown in the backtrace. > > The 5 arguments passed to the "function" at 0x5949 is probably just > > defaulted; I doubt it has any significance. > > > > Long version: > > > > ddb tries to work out the number of arguments passed to a function at a > > particular stack frame first based on symbolic information for the > > function itself (obviously not an option here), then based on the > > instruction at the return address in that frame. This works at best > > sporadically in the face of -O compiled C code. The fact that there's no > > function under the "(null)" would strongly suggest that ddb got confused > > with the frame pointer here and didn't get any useful information with > > which to work out the argument count. > > I don't know how accurate this assumption is. I don't thing > DDB is confused, because the NULL is consistent with the reported > fault address. Even if we assume that it's confused, the PC is > enough information to locate the function pointer dereference that > is occurring. I also have to assume that the function pointer is > in scope, since it's able to call through it to fault the kernel. > > > In the face of failure, ddb just wildly prints out the 5 words under the > > stack pointer. > > I did suggest that the correct thing to do would be to decode > what those words were pointing at, and thereby what types the > arguments were... My main point was really just commenting on the your original statement that "He might also want to look for any function pointer that takes 5 arguments". I was assuming that you were suggesting this based on the fact that the stack frame containing the "(null)" indicated 5 arguments passed to the function at 0x5949. DDB has no symbol for this address (it's certainly not a function) and does not know where it returns to (there's is no function below it on the stack). DDB has no other way of working out how many arguments were passed in a particular stack frame. As a result, It is merely showing the first 5 _possible_ argument values to the function. Agreed?