From owner-freebsd-current Mon Mar 19 11:44:55 2001 Delivered-To: freebsd-current@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 0D9DB37B71A for ; Mon, 19 Mar 2001 11:44:51 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id OAA24800; Mon, 19 Mar 2001 14:44:49 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f2JJiJg90509; Mon, 19 Mar 2001 14:44:19 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15030.24979.456223.496566@grasshopper.cs.duke.edu> Date: Mon, 19 Mar 2001 14:44:19 -0500 (EST) To: Dag-Erling Smorgrav Cc: current@freebsd.org Subject: Re: Here's another one for you... In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > db> trace > Debugger(c027d5e1) at Debugger+0x45 > panic(c027c420,c027a154,c02997d0,356,d3f14ee0) at panic+0x144 > witness_enter(d3f15000,0,c02997d0,356) at witness_enter+0x355 > trap_pfault(d7345d4c,0,0) at trap_pfault+0x143 > trap(18,10,10,d7345fa8,0) at trap+0x978 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0, esp = 0xd7345d8c, ebp = 0xd7345ed8 --- > (null)(805c3e0,e,d7345f10,0,4) at 0 > postsig(e) at postsig+0x40b > userret(d3f14ee0,d7345fa8,3,0,ffffffff) at userret+0x16 > syscall(2f,2f,2f,bfbffd4c,80873e0) at syscall+0xa03 > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b > db> show witness Where does witness_enter+0x355 map to, in terms of line numbers? I'm seeing a really bizzare thing on alpha (UP, of course) where a process will occasional die with an instruction fault on an address in the kernel's text segment --- witness_exit (../../kern/kern_mutex.c:1262) The only reasonable way for this to happen is the stack getting corrupted and restoreregs() restoring a corrupt PC. I suspect there is some sort of stack smashing going on in the signal code & there are different consequences on different platforms. If so, it looks like x86 might be a better place to debug it, since you seem to be crashing soon after the stack smash happens, not much latter like we are on alpha. The program that most easily exhibits this behaviour is a linux app, ex6 from the linux-threads examples. It basically sits in a loop doing a pthread_create()/pthread_join() of a thread which just exits. Since its linux threads, a lot of signals are flying around. I don't have an x86 running current. If you'd like to see if this provokes a similar crash for you, I've left an x86 binary of ex6 at http://www.cs.duke.edu/~gallatin/ex6.x86 Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message