Kernel panic: "General Protection Exception" during running SBCL regression tests

[alpopa]

This bug was reported by Douglas Katzman, an SBCL hacker. It is different from #15761 in that Douglas applied some more patches to SBCL. Here is the original message:

There are some issues exposed by the regression suite (things I didn't finish), but I can't actually complete the run because I reliably get a kernel panic (below). I have no vested interest in subscribing to the Haiku bug tracker to file a bug. So if you haven't already reported this exact panic, it may behoove you to do so. I'm running with 8 simulated cores. I could try fewer, but I don't feel like hammering on this problem.

[waddlesplash]

It is different from #15761 in that Douglas applied some more patches to SBCL.

This is probably irrelevant; the kernel panics are likely the same. Nobody has reported the actual backtrace in #15761, so I'm just going to close that one as a dupe of this.

[waddlesplash]

Actually, this backtrace is missing due to the "READ/WRITE FAULT". Please run sc -d at the KDL prompt the next time you encounter this; that should get past that and show the real backtrace.

[alpopa]

Douglas has KDL during running in tests folder the following:

./parallel-exec.sh 8

I performed this test several times and, while the system froze with CPU usage almost 100%, could not reproduce KDL. It may be unrelated to SBCL but to running Haiku in Qemu (I tested on real hardware). I will test this scenario more extensively to see if I can find any pattern.

[alpopa]

Attached file sc-d.txt as output of sc -d by Douglas.

[waddlesplash]

and, while the system froze with CPU usage almost 100%, could not reproduce KDL.

If you have a PS/2 keyboard, try running Alt+PrntScrn+D; this will drop you directly to the KDL prompt and you can run a backtrace from there.

[waddlesplash]

I'm not sure what to make of this backtrace; it looks like it's occuring in _start directly, but how can that be when the system has been running for a while? CC'ing korli for his analysis.

[alpopa]

If you have a PS/2 keyboard, try running Alt+PrntScrn+D; this will drop you directly to the KDL prompt and you can run a backtrace from there.

I test on iMac which doesn't have PS/2 port. I will try to do the same on PC with this port and PS/2 keyboard.

[alpopa]

I also had KDL several times (attachments KDL1.jpg, KDL2.jpg, KDL3.jpg, KDL4.jpg). The exception is reported as "x87 Floating-Point Error".

[waddlesplash]

That's #14802.

[alpopa]

It is possible that KDL on my system is identical to #14802 but it seems to be different from Douglas' KDL reported here.

[alpopa]

New attachment when the system restarted after quite long compilation - syslog.compilation-long. It may be related to #15817.

[alpopa]

Retested in Qemu. KDL and result of sc -d are attached: kdl-vm.png and sc-d-vm.png.

[alpopa]

After KDL during compilation, I restarted the system and then new KDL occurred during booting, very similar to Douglas' one - kdl2-vm.png.

[alpopa]

Haiku hrev54010 x86_64 is used in Qemu testing.

[X512]

What Qemu version are you using? Does hardware acceleration enabled? If enabled, what virtualization system is used (KVM etc) and what CPU model is on host system?

[alpopa]

I am using Qemu 4.2.0 for Windows. KVM is disabled, TCG is enabled. The host system is Intel Core i7 7820HQ 2.9 GHz with 32 GB RAM.

[alpopa]

Complete VM configuration is attached - haiku.json.

[korli]

alpopa, any change to check this bug on a current nightly image? It could be fixed as of hrev55135.

[alpopa]

Unfortunately, the KDL is still here. I will attach new logs and screenshots.

[alpopa]

KDL on hrev55161

[alpopa]

Syslog on hrev55161 (hopefully it is relevant)

[korli]

Please check with hrev57363 or newer