Re: page fault in ip6_output

On 9/2/18 6:17 AM, Alexander Leidinger wrote:
> Hi,
> 
> -current at r338322 with manually applied r338372 (fix potential data
> corruption in iflib) and r338416 (re-compute arc size).
> 
> What worries me a little bit about the validity of this report is the
> gdb 8.1.1 error when loading the dump/kernel:
> ---snip---
> warning: kld_current_sos: Can't read filename: Unknown error: -1
> 
> inferior.c:311: internal-error: struct inferior *find_inferior_pid(int):
> Assertion `pid != 0' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) [answered Y; input not from terminal]
> 
> This is a bug, please report it.  For instructions, see:
> <http://www.gnu.org/software/gdb/bugs/>.
> 
> inferior.c:311: internal-error: struct inferior *find_inferior_pid(int):
> Assertion `pid != 0' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Create a core file of GDB? (y or n) [answered Y; input not from terminal]
> Abort trap (core dumped)
> ---snip---
> 
> kernel panic:
> ---snip---
> Unread portion of the kernel message buffer:
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 5; apic id = 13
> fault virtual address   = 0x98
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x20:0xffffffff8068cbf2
> stack pointer           = 0x28:0xfffffe0128caa510
> frame pointer           = 0x28:0xfffffe0128caa760
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 1658 (isc-worker0003)
> trap number             = 12
> panic: page fault
> cpuid = 5
> time = 1535835179
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfffffe0128caa1c0
> vpanic() at vpanic+0x1a3/frame 0xfffffe0128caa220
> panic() at panic+0x43/frame 0xfffffe0128caa280
> trap_fatal() at trap_fatal+0x35f/frame 0xfffffe0128caa2d0
> trap_pfault() at trap_pfault+0x49/frame 0xfffffe0128caa330
> trap() at trap+0x2ba/frame 0xfffffe0128caa440
> calltrap() at calltrap+0x8/frame 0xfffffe0128caa440
> --- trap 0xc, rip = 0xffffffff8068cbf2, rsp = 0xfffffe0128caa510, rbp =
> 0xfffffe0128caa760 ---
> ip6_output() at ip6_output+0xf82/frame 0xfffffe0128caa760
> udp6_send() at udp6_send+0x702/frame 0xfffffe0128caa920
> sosend_dgram() at sosend_dgram+0x346/frame 0xfffffe0128caa980
> kern_sendit() at kern_sendit+0x170/frame 0xfffffe0128caaa10
> sendit() at sendit+0x19e/frame 0xfffffe0128caaa60
> sys_sendmsg() at sys_sendmsg+0x61/frame 0xfffffe0128caaac0
> amd64_syscall() at amd64_syscall+0x254/frame 0xfffffe0128caabf0
> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe0128caabf0
> --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x8015adf0a, rsp =
> 0x7fffdf9f7218, rbp = 0x7fffdf9f7250 ---
> Uptime: 22h37m4s
> Dumping 13174 out of 61352
> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
> ---snip---
> 
> I can not reproduce it at will, but it happens often enough (from once a
> day to several times after each reboot).
> 
> Can this gdb be trusted? If yes, which frame do you want to see more
> detailed?
> 
> Bye,
> Alexander.
> 


I think, you have hit this, no?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230950