Re: NULL pointer dereference panic

On Mon, 19 Jun 2006, Yar Tikhiy wrote:

:On Sun, Jun 18, 2006 at 03:26:10PM -0400, Andrew R. Reiter wrote:
:> Hi Peter,
:> 
:> On Mon, 19 Jun 2006, Peter Jeremy wrote:
:> 
:> :I got the following panic is a fresh -current.  Unfortunately, it didn't
:> :do a crash dump - I'm not sure why.  Has anyone else seen this?
:> 
:> I saw a commit from Yar T. earlier that was intended to help in call stack 
:> tracing.  this is just a guess as to a possible cause.
:
:I'm afraid that this panic hardly has to do with my change.  OTOH,
:Peter's kernel seems to be built with some additional optimization
:of the function prologue/epilogue; hence the funny line on fdrop().

Ah, sorry to infer that... Was going through emails and was just hoping to 
help.  Thanks for the work on doing stack traces and making them more 
reliable.

Cheers,
Andrew

:
:Peter, what gcc options did you build the kernel with?  My question
:is unrelated to the panic, I'd just like to make stack traces look
:sane in common cases :-)
:
:> :
:> :Fatal trap 12: page fault while in kernel mode
:> :fault virtual address    = 0x2c
:> :fault code               = supervisor read, page not present
:> :instruction pointer      = 0x20:0xc052cf96
:> :stack pointer            = 0x28:0xd6690970
:> :frame pointer            = 0x28:0xd6690990
:> :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          = 97180 (script)
:> :trap number              = 12
:> :panic: page fault
:> :KDB: stack backtrace:
:> :kdb_backtrace(c07008a8,c076ac80,c06eb1ad,d6690844,100,...) at kdb_backtrace+0x2e
:> :panic(c06eb1ad,c0702b35,d6690930,1,1,...) at panic+0xb7
:> :trap_fatal(d6690930,2c,c071dc0f,2fd,c2b6f6c0,...) at trap_fatal+0x30e
:> :trap_pfault(d6690930,0,2c,c054f7e1,2c,...) at trap_pfault+0x1ba
:> :trap(8,28,28,c0709faa,1a3,...) at trap+0x461
:> :calltrap() at calltrap+0x5
:> :--- trap 0xc, eip = 0xc052cf96, esp = 0xd6690970, ebp = 0xd6690990 ---
:> :_mtx_lock_flags(24,0,c0709faa,1a3,0,...) at _mtx_lock_flags+0x46
:> :vfs_ref(0,d66909f8,0,d66909dc,c06d4f68,...) at vfs_ref+0x32
:> :vop_stdgetwritemount(d66909f8,c076ea74,d66909f0,d6690a2c,d6690a14,...) at vop_stdgetwritemount+0x1d
:> :VOP_GETWRITEMOUNT_APV(c073df20,d66909f8,c07b4988,c06fe125,d6690a0c,...) at VOP_GETWRITEMOUNT_APV+0xa8
:> :vn_start_write(c4251000,d6690a2c,1,2,c0701fa5,...) at vn_start_write+0x37
:> :vn_close(c4251000,3,c2f37780,c2b6f6c0,6b5,...) at vn_close+0x65
:> :vn_closefile(c370c750,c2b6f6c0,d6690af0,c0512cce,c370c750,...) at vn_closefile+0xe9
:> :devfs_close_f(c370c750,c2b6f6c0,c06fca41,876,c370c750,...) at devfs_close_f+0x19
:> :fdrop_locked(c370c750,c2b6f6c0,c06fca41,861) at fdrop_locked+0xbe
:> :fdrop(c370c750,c2b6f6c0,d6690b38,c0567d6f,c076ea74,0,c07046e5,6b5,c07b4a6c,d6690b68,0,c07b4a68,d6690b64,c0566bba,0,c394872c,246,c0744d24,c394872c,661,c06fca41,d6690b8c,c052d0f2,c394872c,1,c06ff4e5,13
:> :
:> :closef(c370c750,c2b6f6c0,c06fca41,661,c07b4a68,...) at closef+0x427
:> :fdfree(c2b6f6c0,0,c06fd2c3,106,d6690c50,...) at fdfree+0x5c6
:> :exit1(c2b6f6c0,0,d6690d30,c06bf073,c2b6f6c0,...) at exit1+0x57b
:> :sys_exit(c2b6f6c0,d6690d04,4,c2b6f6c0,c33f0000,...) at sys_exit+0x1d
:> :syscall(3b,3b,3b,1,0,...) at syscall+0x2e3
:> :Xint0x80_syscall() at Xint0x80_syscall+0x1f
:> :--- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x281012fb, esp = 0xbfbfe1ec, ebp = 0xbfbfe1f8 ---
:> :
:> :-- 
:> :Peter Jeremy
:> :
:> 
:> --
:> arr_at_watson.org
:> _______________________________________________
:> freebsd-current_at_freebsd.org mailing list
:> http://lists.freebsd.org/mailman/listinfo/freebsd-current
:> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
:
:-- 
:Yar
:
:

--
arr_at_watson.org