Re: Panic in sys_fstatat()

On 2/13/19 6:47 PM, Steve Kargl wrote:
> I have the core file and kernel.debug, if someone 
> wnat additional information.
> 
> mobile dumped core - see /var/crash/vmcore.0
> 
> Wed Feb 13 18:37:44 PST 2019
> 
> FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r344034M: Tue Feb 12 08:14:16 PST 2019     root_at_mobile:/usr/obj/usr/src/i386.i386/sys/MOBILE  i386
> 
> panic: vm_fault_hold: fault on nofault entry, addr: 0x202000
> 
> GNU gdb (GDB) 8.2.1 [GDB v8.2.1 for FreeBSD]
> Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done.
> done.
> 
> Unread portion of the kernel message buffer:
> panic: vm_fault_hold: fault on nofault entry, addr: 0x202000
> cpuid = 1
> time = 1550111772
> KDB: stack backtrace:
> db_trace_self_wrapper(10b42f3,8c96000,1,9341bd0,2e7b6590,...) at db_trace_self_wrapper+0x2a/frame 0x2e7b6560
> kdb_backtrace(109973a,5c64d41c,0,2e7b661c,1,...) at kdb_backtrace+0x2d/frame 0x2e7b65c8
> vpanic(108d309,2e7b661c,2e7b661c,2e7b6700,f734a9,...) at vpanic+0x141/frame 0x2e7b65fc
> panic(108d309,103dfa3,202000,2e7b6664,2e7b6654,...) at panic+0x1b/frame 0x2e7b6610
> vm_fault_hold(1ea5000,202000,1,0,0,...) at vm_fault_hold+0x29e9/frame 0x2e7b6700
> vm_fault(1ea5000,202000,1,0,0,...) at vm_fault+0x5e/frame 0x2e7b6728
> trap_pfault(202462,40,109e2f2,316d3480,2e7b67c0,...) at trap_pfault+0xb2/frame 0x2e7b6770
> trap(2e7b6880,8,28,28,1836a120,...) at trap+0x3cb/frame 0x2e7b6874
> calltrap() at PTDpde+0x4165/frame 0x2e7b6874
> --- trap 0xc, eip = 0x1027fb8, esp = 0x2e7b68c0, ebp = 0x2e7b68f8 ---
> VOP_LOCK1_APV(1836a120,202400,1099cc5,2c8,2e7b6ab0,...) at VOP_LOCK1_APV+0x8/frame 0x2e7b68f8
> lookup(2e7b6a50,0,400,2e7b6aa0,2e7b6a18,...) at lookup+0xc4/frame 0x2e7b6960
> namei(2e7b6a50,0,4000144,0,2cced08e,...) at namei+0x4f3/frame 0x2e7b6a20
> kern_statat(3c5dc700,0,ffffff9c,2cced08e,0,...) at kern_statat+0x85/frame 0x2e7b6af0
> sys_fstatat(3c5dc700,3c5dc988,1384bb0,3c5dc700,0,...) at sys_fstatat+0x49/frame 0x2e7b6c00
> syscall(2e7b6ce8,3b,3b,3b,fbafbbc8,...) at syscall+0x3ea/frame 0x2e7b6cdc
> Xint0x80_syscall() at PTDpde+0x43af/frame 0x2e7b6cdc
> --- syscall (552, FreeBSD ELF32, sys_fstatat), eip = 0x21321d5f, esp = 0xfbafbb2c, ebp = 0xfbafbbb8 ---
> _DYNAMIC() at 0x21321d5f
> KDB: enter: panic
> 
> __curthread () at ./machine/pcpu.h:226
> 226		__asm("movl %%fs:%1,%0" : "=r" (td)
> (kgdb) #0  __curthread () at ./machine/pcpu.h:226
> #1  doadump (textdump=<optimized out>)
>     at /usr/src/sys/kern/kern_shutdown.c:371
> #2  0x009c023d in db_fncall_generic (addr=<optimized out>, 
>     rv=<optimized out>, nargs=<optimized out>, args=<optimized out>)
>     at /usr/src/sys/ddb/db_command.c:609
> #3  db_fncall (dummy1=20441604, dummy2=false, dummy3=10607414, 
>     dummy4=0x2e7b6344 "") at /usr/src/sys/ddb/db_command.c:657
> #4  0x009bfd74 in db_command (last_cmdp=<optimized out>, 
>     cmd_table=<optimized out>, dopager=1) at /usr/src/sys/ddb/db_command.c:481
> #5  0x009bfae0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534
> #6  0x009c2d6b in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:252
> #7  0x00ca66d4 in kdb_trap (type=3, code=0, tf=0x2e7b657c)
>     at /usr/src/sys/kern/subr_kdb.c:692
> #8  0x00ff58a4 in trap (frame=0x2e7b657c) at /usr/src/sys/i386/i386/trap.c:712
> #9  0xffc0315d in ?? ()
> #10 0x2e7b657c in ?? ()
> #11 0x00c5bede in vpanic (
>     fmt=0x108d309 "%s: fault on nofault entry, addr: %#lx", 
>     ap=0x2e7b661c "\243\337\003\001") at /usr/src/sys/kern/kern_shutdown.c:866
> #12 0x00c5bd7b in panic (
>     fmt=0x108d309 "%s: fault on nofault entry, addr: %#lx")
>     at /usr/src/sys/kern/kern_shutdown.c:804
> #13 0x00f734a9 in vm_fault_hold (map=0x1ea5000, vaddr=2105344, 
>     fault_type=1 '\001', fault_flags=0, m_hold=0x0)
>     at /usr/src/sys/vm/vm_fault.c:586
> #14 0x00f70a6e in vm_fault (map=0x1ea5000, vaddr=2105344, 
>     fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:536
> #15 0x00ff62b2 in trap_pfault (frame=0x2e7b6880, usermode=0, eva=2106466)
>     at /usr/src/sys/i386/i386/trap.c:882
> #16 0x00ff58bb in trap (frame=0x2e7b6880) at /usr/src/sys/i386/i386/trap.c:519
> #17 0xffc0315d in ?? ()
> #18 0x2e7b6880 in ?? ()
> #19 0x00d1de64 in lookup (ndp=0x2e7b6a50)
>     at /usr/src/sys/kern/vfs_lookup.c:710
> #20 0x00d1d763 in namei (ndp=0x2e7b6a50) at /usr/src/sys/kern/vfs_lookup.c:487
> #21 0x00d372c5 in kern_statat (td=0x3c5dc700, flag=0, fd=-100, 
>     path=0x2cced08e <error: Cannot access memory at address 0x2cced08e>, 
>     pathseg=UIO_USERSPACE, sbp=0x2e7b6b18, hook=0x0)
>     at /usr/src/sys/kern/vfs_syscalls.c:2307
> #22 0x00d37c99 in sys_fstatat (td=0x3c5dc700, uap=0x3c5dc988)
>     at /usr/src/sys/kern/vfs_syscalls.c:2284
> #23 0x00ff69fa in syscallenter (td=<optimized out>)
>     at /usr/src/sys/i386/i386/../../kern/subr_syscall.c:135
> #24 syscall (frame=0x2e7b6ce8) at /usr/src/sys/i386/i386/trap.c:1144
> #25 0xffc033a7 in ?? ()
> #26 0x2e7b6ce8 in ?? ()
> Backtrace stopped: Cannot access memory at address 0xfbafbbbc
> (kgdb) 

Frame 18 is probably the root problem, though it doesn't look like kgdb is
able to unwind it correctly.  Looking at frame 19 might help though.  It
seems like a NULL pointer dereference when invoking VOP_LOCK.

-- 
John Baldwin