From owner-freebsd-current@FreeBSD.ORG Tue Aug 12 09:11:28 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 E018837B401 for ; Tue, 12 Aug 2003 09:11:28 -0700 (PDT) Received: from sweeper.openet-telecom.com (mail.openet-telecom.com [62.17.151.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31B4643F85 for ; Tue, 12 Aug 2003 09:11:27 -0700 (PDT) (envelope-from peter.edwards@openet-telecom.com) Received: from mail.openet-telecom.com (unverified) by sweeper.openet-telecom.com ; Tue, 12 Aug 2003 17:14:57 +0100 Received: from [10.0.0.40] (10.0.0.40) by mail.openet-telecom.com (NPlex 6.5.027) id 3F268E00000084B6; Tue, 12 Aug 2003 17:09:39 +0100 From: Peter Edwards To: Terry Lambert In-Reply-To: <3F38D515.2950D743@mindspring.com> References: <20030811100549.GA33392@technokratis.com> <20030811130937.GA34564@technokratis.com> <3F38D515.2950D743@mindspring.com> Content-Type: text/plain Organization: Openet Telecom Message-Id: <1060704284.45511.118.camel@rocklobster.openet-telecom.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 12 Aug 2003 17:04:45 +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: Tue, 12 Aug 2003 16:11:29 -0000 On Tue, 2003-08-12 at 12:52, Terry Lambert wrote: > Bosko Milekic wrote: > > > db> trace > > > _mtx_lock_flags(0,0,c07aa287,11e,c0c21aaa) at _mtx_lock_flags+0x43 > > > vm_fault(c102f000,c0000000,2,0,c08205c0) at vm_fault+0x2b4 > > > trap_pfault(c0c21b9e,0,c00004d8,100000,c00004d8) at trap_pfault+0x152 > > > trap(6c200018,10,1bc40060,1c,0) at trap+0x30d > > > calltrap() at calltrap+0x5 > > > --- trap 0xc, eip = 0x5949, esp = 0xc0c21bde, dbp = 0xc0c21be4 --- > > > (null)(1bf80058,0,530e0102,80202,505a61) at 0x5949 > > > db> > > ... 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. In the face of failure, ddb just wildly prints out the 5 words under the stack pointer. Given that there's no real function at 0x5949, the stack frame won't have been set up at all, the frame pointer is still pointing to the caller's frame, which could be foobar anyway. What can be useful is to print out the values on the stack symbolically. (in gdb, p/a ((void **)$sp)[0]@100. I'm sure ddb can do something similar, but no idea how...). And hope to find the caller's return address lying in the output. HTH, Peter.