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: [EMAIL PROTECTED]
Department of Computer Science          Phone: (919) 660-6590

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to