Created attachment 249951 [details]
VirtualBox_FBSD-CUR_13_04_2024_19_26_12.png

Created attachment 249952 [details]
VirtualBox_FBSD-CUR_13_04_2024_19_29_02.png

Created attachment 249953 [details]
VirtualBox_FBSD-CUR_13_04_2024_19_29_46.png

Created attachment 249954 [details]
VirtualBox_FBSD-CUR_13_04_2024_19_30_08.png

Created attachment 249955 [details]
VirtualBox_FBSD-CUR_13_04_2024_19_30_23.png

Created attachment 249956 [details]
VirtualBox_FBSD-CUR_13_04_2024_19_30_38.png

Created attachment 249957 [details]
VirtualBox_FBSD-CUR_13_04_2024_19_30_54.png

Comment 8 Mark Johnston 2024-04-13 16:51:41 UTC

The stack pointer is very close to a page boundary, so this looks a bit like a stack overflow.  There is not a lot of other useful detail.

Is it reproducible?  If so, I wonder if reverting commit 7a79d066976149349ecb90240d02eed0c4268737 fixes the problem.

(In reply to Mark Johnston from comment #8)
Thank you for reply.

It is not reproduceable fast and I don't have enough time for thorough continuous heavy, overloading testing (like compiling world). 

But on FBSD side, using fast servers, it is possible to run such burning, automated extended stress-test of example before release, including VMM just RAM and RAM + Swap configuration, paying precise attention to large scale testing like 128GB of RAM & 256GB of Swap, and 64 threads (-j 64) for 32 threads CPU, which easily could be achieved by compiling LLVM source code (and simultaneously in multiple jails), for e.g.

I'll be waiting for new kernel commits in up-coming weeks.

Comment 10 Mark Johnston 2024-04-15 13:44:39 UTC

> It is not reproduceable fast

Is it reproducible at all?  I am asking if you saw it more than once.

(In reply to Mark Johnston from comment #10)
No, just once.

Comment 12 Gleb Smirnoff 2024-04-23 17:40:17 UTC

Any more occurrences of this panic?

(In reply to Gleb Smirnoff from comment #12)
No.