fdescfs kernel panic on 10.1-RELEASE
Mahmoud Al-Qudsi
mqudsi at neosmart.net
Sun Dec 21 13:40:50 UTC 2014
Hello all,
I have two very-similarily configured virtual machines, one of which will
instantly go into a kernel panic and reboots when I attempt to launch Chrome
(as a normal user, without root priviliges).
This is running on FreeBSD 10.1-RELEASE i386, under XOrg with the VESA driver.
Even though my kernel is built with BREAK_TO_DEBUGGER, Chromimum always causes
a hard restart of the entire machine - though KDB does print the kernel
stacktrace. Any idea how I can catch this?
Without ddb, I'm not sure where to go next to debug the issue.
This is the stack trace as reported by KDB on the serial console, and I've
attached the output of dtruss for the process in question.
Many thanks,
Mahmoud Al-Qudsi
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 820 (chrome)
trld-elf.so.1`0x2dap n746cfb
umber = 12
panic: page fault
cpuid = 5
KDB: stack backtrace:
db_trace_self_wrapper(c11ca238,c141f650,c65fc620,c5b26478,c095dc76,...) at db_trace_self_wrapper+0x2d/frame 0xc5b26448
kdb_backtrace(c138ccff,5,c1095b1c,c5b26504,c5db0cc8,...) at kdb_backtrace+0x30/frame 0xc5b264b0
vpanic(c5b26504,c5b26548,c104cd24,c1095b1c,c138e74d,...) at vpanic+0x11d/frame 0xc5b264ec
panic(c1095b1c,c138e74d,c65fc7c8,1,1,...) at panic+0x12/frame 0xc5b264f8
trap_fatal(5,0,c138e746,246,c107be3f,...) at trap_fatal+0x324/frame 0xc5b26548
trap_pfault(c,c,c65fc620,c5b265e0,246,...) at trap_pfault+0x72/frame 0xc5b265c0
trap(c5b26714) at trap+0x75e/frame 0xc5b26708
calltrap() at calltrap+0x6/frame 0xc5b26708
--- trap 0xc, eip = 0xc0c0363d, esp = 0xc5b26754, ebp = 0xc5b2675c ---
strlen(f,c5b26848,c11c3301,246,c11c32a8,...) at strlen+0xd/frame 0xc5b2675c
kvprintf(c11c328f,c0b7b3b0,c5b26848,a,c5b26890,...) at kvprintf+0x81e/frame 0xc5b26828
vsnprintf(c153c0b2,100,c11c328f,c5b26890,c5b26890,...) at vsnprintf+0x45/frame 0xc5b26860
kassert_panic(c11c328f,f,c655d0ef,b5,0,...) at kassert_panic+0x2d/frame 0xc5b26884
__mtx_lock_flags(c66ccba4,0,c655d0ef,b5,c65fc620,...) at __mtx_lock_flags+0x17e/frame 0xc5b268b8
fdesc_allocvp(1,0,3,c65ca000,c5b26918,...) at fdesc_allocvp+0xad/frame 0xc5b268e8
fdesc_lookup(c5b269a8,c1395423,c11fbb35,c11d6ef8,c14798f0,...) at fdesc_lookup+0x1f0/frame 0xc5b26940
VOP_LOOKUP_APV(c655e2f8,c5b269a8,c5b26b64,31b,0,...) at VOP_LOOKUP_APV+0x12f/frame 0xc5b26970
lookup(c5b26b08,c5b26a40,110,d5,1101,...) at lookup+0x514/frame 0xc5b269d0
namei(c5b26b08,0,4000144,0,bf9fd6d1,...) at namei+0x4fd/frame 0xc5b26a68
kern_statat_vnhook(c65fc620,0,ffffff9c,bf9fd6d1,0,...) at kern_statat_vnhook+0xbd/frame 0xc5b26ba8
sys_stat(c65fc620,c5b26cc8,c14385b4,c5b26cc8,0,...) at sys_stat+0x5a/frame 0xc5b26c40
syscall(c5b26d08) at syscall+0x31b/frame 0xc5b26cfc
Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xc5b26cfc
--- syscall (188, FreeBSD ELF32, sys_stat), eip = 0x2f0536e7, esp = 0xbf9fd68c, ebp = 0xbf9fd898 —
-------------- next part --------------
More information about the freebsd-stable
mailing list