https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283747
--- Comment #52 from Евгений Килимчук <ekilimc...@gmail.com> --- Hi! I reproduced the bug in 14.2 with debugging. I wrote similar Go code to reproduce it: https://github.com/ekilimchuk/junk/blob/main/fork-test/README.md After waiting for a week, I reproduced the issue (crunuse’s ref overflow). ekilimchuk@test-fw-debug01:~$ cat core/crash/info.0 Dump header from device: /dev/da1 Architecture: amd64 Architecture Version: 2 Dump Length: 304893952 Blocksize: 512 Compression: none Dumptime: 2025-03-31 10:25:04 +0000 Hostname: test-fw-debug01 Magic: FreeBSD Kernel Dump Version String: FreeBSD 14.2-RELEASE-p2 releng/14.2-n269518-ac2cbb46b5f1 GENERIC-DEBUG Panic String: crunuse: ref -4294967295 not > 0 on cred 0xfffff8002f045300 Dump Parity: 4010253368 Bounds: 0 Dump Status: good Stack trace: (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 #1 doadump (textdump=textdump@entry=1) at /usr/src/sys/kern/kern_shutdown.c:405 #2 0xffffffff80b4c960 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:523 #3 0xffffffff80b4ce5e in vpanic (fmt=0xffffffff811bd95e "%s: ref %ld not > 0 on cred %p", ap=ap@entry=0xfffffe00037aba60) at /usr/src/sys/kern/kern_shutdown.c:967 #4 0xffffffff80b4cc03 in panic (fmt=<unavailable>) at /usr/src/sys/kern/kern_shutdown.c:891 #5 0xffffffff80b39a15 in crunuse (td=0xfffff800457a7740) at /usr/src/sys/kern/kern_prot.c:1927 #6 0xffffffff80b39909 in crcowfree (td=<unavailable>, td@entry=0xfffff800457a7740) at /usr/src/sys/kern/kern_prot.c:1969 #7 0xffffffff80b657bc in thread_cow_free (td=0xfffff800457a7740) at /usr/src/sys/kern/kern_thread.c:880 #8 thread_wait (p=p@entry=0xfffffe00546adae0) at /usr/src/sys/kern/kern_thread.c:1055 #9 0xffffffff80afe430 in proc_reap (td=td@entry=0xfffff800035c0000, p=p@entry=0xfffffe00546adae0, status=status@entry=0xfffffe00037abde4, options=<optimized out>) at /usr/src/sys/kern/kern_exit.c:1033 #10 0xffffffff80afe874 in proc_to_reap (td=td@entry=0xfffff800035c0000, p=p@entry=0xfffffe00546adae0, idtype=idtype@entry=P_ALL, id=id@entry=0, status=status@entry=0xfffffe00037abde4, options=options@entry=48, wrusage=0x0, siginfo=0x0, check_only=0) at /usr/src/sys/kern/kern_exit.c:1197 #11 0xffffffff80afd9d6 in kern_wait6 (td=td@entry=0xfffff800035c0000, idtype=P_ALL, id=0, status=status@entry=0xfffffe00037abde4, options=48, wrusage=0x0, siginfo=0x0) at /usr/src/sys/kern/kern_exit.c:1326 #12 0xffffffff80afd5fb in kern_wait (status=0xfffffe00037abde4, options=<unavailable>, td=<optimized out>, pid=<optimized out>, rusage=<optimized out>) at /usr/src/sys/kern/kern_exit.c:1238 #13 sys_wait4 (td=0xfffff800035c0000, uap=0xfffff800035c0400) at /usr/src/sys/kern/kern_exit.c:864 #14 0xffffffff81069781 in syscallenter (td=0xfffff800035c0000) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:193 #15 amd64_syscall (td=0xfffff800035c0000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1194 #16 <signal handler called> #17 0x00000000002893da in ?? () Also see a ktrace: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=259233 I have a core dump with invariants and am ready to share the dump. I’ll also try to speed up reproducing the issue. I think it’s related to how Golang specifically handles execv. -- You are receiving this mail because: You are the assignee for the bug.
