Re: Page fault from kdb_backtrace()

On Sat, Apr 29, 2006 at 08:46:38AM +0300, Kostik Belousov wrote:
> On Sat, Apr 29, 2006 at 01:07:52AM -0400, Kris Kennaway wrote:
> > I am testing a patch that has the effect of spewing a lot of
> > kdb_backtraces to the console..but sooner or later it will panic:
> > 
> > trap 12: page fault while in kernel mode
> > cpuid = 1; apic id = 06
> > fault virtual address   = 0xc
> > fault code              = supervisor read, page not present
> > instruction pointer     = 0x20:0xc0466c61
> > stack pointer           = 0x28:0xf599da20
> > frame pointer           = 0x28:0xf599da40
> > code segment            = base 0x0, limit 0xfffff, type 0x1b
> >                         = DPL 0, pres 1, def32 1, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 24902 (mkdir)
> > [thread pid 24902 tid 100129 ]
> > Stopped at      X_db_symbol_values+0x18:        cmpl    $0,0xc(%eax)
> > db> wh
> > Tracing pid 24902 tid 100129 td 0xca7f4bd0
> > X_db_symbol_values(0,c0851b2c,f599da98,f599da58,2f) at X_db_symbol_values+0x18
> > db_symbol_values(c0851b2c,f599da98,0,c05b3c8e,c06f8653) at db_symbol_values+0x41
> > db_backtrace(ca7f4bd0,0,f599db1c,c055e161,ffffffff) at db_backtrace+0x96
> > db_trace_self(c073e687,f599db38,c05b8cd0,c0746e8f,ca7f4bd0) at db_trace_self+0x4d
> > kdb_backtrace(c0746e8f,ca7f4bd0,0,0,0) at kdb_backtrace+0x2f
> > vn_finished_write(ca59787c,ffffffdf,c0746c88,d68,0) at vn_finished_write+0x33
> > kern_mkdir(ca7f4bd0,bfb623a0,0,1f8,f599dd30) at kern_mkdir+0x3a7
> > mkdir(ca7f4bd0,f599dd04,8,445,ccef4528) at mkdir+0x29
> > syscall(2805003b,3b,bfbe003b,28051a1a,24c) at syscall+0x307
> > Xint0x80_syscall() at Xint0x80_syscall+0x1f
> > --- syscall (136, FreeBSD ELF32, mkdir), eip = 0x2813d87b, esp = 0xbfb61f3c, ebp = 0xbfb62378 ---
> > 
> > Why is this happening?
> > 
> > Kris
> 
> Is this true that kdb_backtrace called from several threads at parallel ?

Yes, quite likely.

> Symbol lookup seems to be non-SMP safe.  It looks like global db_last_symtab
> is used unsafely. At least, try to comment the line 233 of sys/ddb/db_sym.c,
> that sets db_last_symtab to NULL.
> 
> Sorry, I cannot test the change now.

I'll give it a try.

Kris