Date: 13 Aug 2003 11:06:13 +0100 From: Peter Edwards <peter.edwards@openet-telecom.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: current@freebsd.org Subject: Re: 5.1, Data Corruption, Intel, Oh my! [patch] - Fatal trap 12 Message-ID: <1060769172.45511.257.camel@rocklobster.openet-telecom.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1060769172.45511.257.camel>