page fault in ip6_output

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.

-- 
http://www.Leidinger.net Alexander_at_Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild_at_FreeBSD.org  : PGP 0x8F31830F9F2772BF