Reproducible panic on 14.1 and 14.2

From: David Cross <david_at_crossfamilyweb.com>
Date: Sat, 07 Jun 2025 04:37:25 UTC
I've been having cases of a reproducible panic on 14.1 and 14.2, but not 
on 14.0.  The situation is that I have a 14.2 server running a number of 
jails, including some that have not been updated since 12.x days (yes, 
yikes, I know -- but it also shouldn't panic).  One of those jails when 
shutting down after some length of time (but not immediately, so I 
cannot just on a whim do this) will reliably panic the system.


Additionally, when it goes down it goes down pretty hard, including 
softupdate/journal errors that I need to manually fsck.. though this 
MIGHT be related to my use of geom mirror and unresolved dirty mirror 
status; since I know it is coming at this point I have taken steps to 
shield me from this, including going to single user immediately upon 
startup and killing all mirrors and force rebuilding them.


This didn't happen on 13.x, and it didn't happen on 14.0, it only 
started when I upgraded to 14.1, and unfortunately continued to 14.2 (I 
reboot very rarely, only for security updates).


Below is the most recent crash dump, I have 2 captured at this level 
now, they are both consistent in in both what process is running (ruby), 
and where the panic is):  The ruby process in question is *most likely* 
(but I do not and cannot know) connected to an apache/mod_passenger process.

This is also a custom kernel, and I had debugging symbols off. FInally, 
I am in the process of retiring that freebsd12 jail for multiple 
reasons, not the least of which being this panic, so I will not be able 
to reproduce; I just post this in the off chance that someone goes 'oh, 
I made this change to freebsd12 syscals around 14.1..I wonder if ....'



Fatal trap 12: page fault while in kernel mode
cpuid = 15; apic id = 0f
fault virtual address   = 0x40
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0xffffffff805f1f56
stack pointer           = 0x28:0xfffffe01ca7dab98
frame pointer           = 0x28:0xfffffe01ca7dabe0
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         = 8564 (ruby26)
rdi: 0000000000000000 rsi: fffffffffffff000 rdx: 0000000000000000
rcx: fffffffffffff000  r8: 000000000000003b  r9: 0000000000000000
rax: fffff80001e87e00 rbx: fffffe01c91db718 rbp: fffffe01ca7dabe0
r10: 0000000000000218 r11: ffffffff80664390 r12: fffffe01c91db85c
r13: fffffe01c91db7d8 r14: fffff80c538c1740 r15: fffffe01c91db5c0
trap number             = 12
panic: page fault
cpuid = 15
time = 1748715227
KDB: stack backtrace:
#0 0xffffffff80640d43 at kdb_backtrace+0x63
#1 0xffffffff805f864f at vpanic+0x12f
#2 0xffffffff805f8513 at panic+0x43
#3 0xffffffff809c93ab at trap_fatal+0x40b
#4 0xffffffff809c93f6 at trap_pfault+0x46
#5 0xffffffff809a1d1e at calltrap+0x8
#6 0xffffffff806643e8 at pipe_close+0x58
#7 0xffffffff8059e3c7 at _fdrop+0x17
#8 0xffffffff805a1271 at closef+0x201
#9 0xffffffff805a0a0a at fdescfree+0x47a
#10 0xffffffff805b2775 at exit1+0x435
#11 0xffffffff805b233d at sys_exit+0xd
#12 0xffffffff809c9c4a at amd64_syscall+0x11a
#13 0xffffffff809a263b at fast_syscall_common+0xf8
Uptime: 44d12h17m14s