Created attachment 256361 [details] core.txt.0 Hi, Before the crash, I looked on Twitch and compiled xray-engine. FreeBSD hades 14.2-RELEASE FreeBSD 14.2-RELEASE releng/14.2-n269506-c8918d6c7412 GENERIC amd64 Fatal trap 12: page fault while in kernel mode cpuid = 11; apic id = 0d fault virtual address = 0x30 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80b66712 stack pointer = 0x28:0xfffffe0132b03cc0 frame pointer = 0x28:0xfffffe0132b03d80 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 82959 (MediaDecoderStateMa) rdi: fffffe001b223020 rsi: 0000000000000000 rdx: 0000000000000000 rcx: 0000000000000000 r8: 0000000000000201 r9: 0000000000000580 rax: 0000000000000030 rbx: fffff80073fd5c00 rbp: fffffe0132b03d80 r10: 0000000000000000 r11: 0000000000000004 r12: 000038b47428f108 r13: ffffffff81bbcad0 r14: ffffffff81bb2ad0 r15: 0000000000000000 trap number = 12 panic: page fault cpuid = 11 time = 1735851846 KDB: stack backtrace: #0 0xffffffff80b8b89d at kdb_backtrace+0x5d #1 0xffffffff80b3dc01 at vpanic+0x131 #2 0xffffffff80b3dac3 at panic+0x43 #3 0xffffffff81025a0b at trap_fatal+0x40b #4 0xffffffff81025a56 at trap_pfault+0x46 #5 0xffffffff80ffc398 at calltrap+0x8 #6 0xffffffff80b61fc6 at __umtx_op_lock_umutex+0x46 #7 0xffffffff80b60b7e at sys__umtx_op+0x7e #8 0xffffffff810262c5 at amd64_syscall+0x115 #9 0xffffffff80ffccab at fast_syscall_common+0xf8 Uptime: 2d13h44m10s
More context from Discord's FreeBSD kernel Channel: JordanG: Okay, the code is buggy. umtx_pi_alloc(M_NOWAIT) is called. The flag M_NOWAITmeans that NULL is returned if the memory allocation request cannot be satisfied immediately. The call to the memory allocation routine uma_zalloc fails and returns NULL. umtx_pi_alloc() receives the NULL pointer and immediately, without checking it, tries to access a structure's field via the pointer. And also: JordanG: @maxfx You've discovered a genuine bug that is also present in FreeBSD 15-CURRENT.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=50c1e179b584f43ba82e9afc91b25ec4831b58ef commit 50c1e179b584f43ba82e9afc91b25ec4831b58ef Author: Kristof Provost <kp@FreeBSD.org> AuthorDate: 2025-01-05 16:09:08 +0000 Commit: Kristof Provost <kp@FreeBSD.org> CommitDate: 2025-01-05 17:19:56 +0000 umtx: handle allocation failire in umtx_pi_alloc() Don't assume that this allocation will succeed. We may have been passed M_NOWAIT. The calling code already handles allocation failures, but the function itself did not. PR: 283807 MFC after: 1 week sys/kern/kern_umtx.c | 3 +++ 1 file changed, 3 insertions(+)
Similar error with 14.2-RELEASE-p0 for the past 2/3 days.... kernel: Fatal trap 12: page fault while in kernel mode kernel: cpuid = 2; apic id = 02 kernel: fault virtual address = 0x5c kernel: fault code = supervisor read data, page not present kernel: instruction pointer = 0x20:0xffffffff821ed0c9 kernel: stack pointer = 0x28:0xfffffe01442725a0 kernel: frame pointer = 0x28:0xfffffe01442725e0 kernel: code segment = base rx0, limit 0xfffff, type 0x1b kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 kernel: processor eflags = interrupt enabled, resume, IOPL = 0 kernel: current process = 4698 (pkg) kernel: rdi: ffffffff824b1d40 rsi: 89cadb0d77df630a rdx: fb07dd1e3ec0c464 kernel: rcx: 0000000000000078 r8: 01b5ca7c2137e8b3 r9: df95c4a4189833e0 kernel: rax: 000000000000005c rbx: fffff802d34e7740 rbp: fffffe01442725e0 kernel: r10: 0000000000000180 r11: fffff8051dff0a08 r12: 00000000000005a8 kernel: r13: 000000000002cbfd r14: fffffe01442726f8 r15: 000000000032bda8 kernel: trap number = 12 kernel: panic: page fault kernel: cpuid = 2 kernel: time = 1736067785 kernel: KDB: stack backtrace: kernel: #0 0xffffffff80b8b89d at kdb_backtrace+0x5d kernel: #1 0xffffffff80b3dc01 at vpanic+0x131 kernel: #2 0xffffffff80b3dac3 at panic+0x43 kernel: #3 0xffffffff81025a0b at trap_fatal+0x40b kernel: #4 0xffffffff81025a56 at trap_pfault+0x46 kernel: #5 0xffffffff80ffc398 at calltrap+0x8 kernel: #6 0xffffffff821ebc83 at arc_read+0x1c3 kernel: #7 0xffffffff82208a13 at dbuf_issue_final_prefetch+0x93 kernel: #8 0xffffffff822080c4 at dbuf_prefetch_impl+0x434 kernel: #9 0xffffffff82230b32 at dmu_zfetch_run+0x1c2 kernel: #10 0xffffffff82212815 at dmu_buf_hold_array_by_dnode+0x2a5 kernel: #11 0xffffffff8221406a at dmu_read_uio_dnode+0x3a kernel: #12 0xffffffff8221419e at dmu_read_uio_dbuf+0x3e kernel: #13 0xffffffff823611ca at zfs_read+0x1ea kernel: #14 0xffffffff821cb4e9 at zfs_freebsd_read+0x39 kernel: #15 0xffffffff810eb780 at VOP_READ_APV+0x20 kernel: #16 0xffffffff80c429ec at vn_read+0x1ec kernel: #17 0xffffffff80c42755 at vn_io_fault_doio+0x45
(In reply to John Darrah from comment #3) Given the lack of: . . . at __umtx_op_lock_umutex+0x?? . . . at sys__umtx_op+0x?? It does not look like the same error to me.
(In reply to Mark Millard from comment #4) Yes, the issue in comment #3 is not related and should have its own bug report, if there is not one already.
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2e2c4e312ef1adfc21f7f8264082b3027f7a1931 commit 2e2c4e312ef1adfc21f7f8264082b3027f7a1931 Author: Kristof Provost <kp@FreeBSD.org> AuthorDate: 2025-01-05 16:09:08 +0000 Commit: Kristof Provost <kp@FreeBSD.org> CommitDate: 2025-01-12 09:47:03 +0000 umtx: handle allocation failire in umtx_pi_alloc() Don't assume that this allocation will succeed. We may have been passed M_NOWAIT. The calling code already handles allocation failures, but the function itself did not. PR: 283807 MFC after: 1 week (cherry picked from commit 50c1e179b584f43ba82e9afc91b25ec4831b58ef) sys/kern/kern_umtx.c | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=dfd9c9bc3f8627a15443f9bfc068a7eade2d688c commit dfd9c9bc3f8627a15443f9bfc068a7eade2d688c Author: Kristof Provost <kp@FreeBSD.org> AuthorDate: 2025-01-05 16:09:08 +0000 Commit: Kristof Provost <kp@FreeBSD.org> CommitDate: 2025-01-12 09:46:31 +0000 umtx: handle allocation failire in umtx_pi_alloc() Don't assume that this allocation will succeed. We may have been passed M_NOWAIT. The calling code already handles allocation failures, but the function itself did not. PR: 283807 MFC after: 1 week (cherry picked from commit 50c1e179b584f43ba82e9afc91b25ec4831b58ef) sys/kern/kern_umtx.c | 3 +++ 1 file changed, 3 insertions(+)
^Triage: committed and merged.