VM crashes upon switching away and back with a KVMS

[systemdlete]

(Note: I will use "KVMS" to mean keyboard-video-mouse switch in order to distinguish this from KVM, which may come up in this ticket since this problem has to do with virtualization.)

I have several PCs connected through a USB KVMS switch. I have observed this problem with a different KVMS as well. The KVMS has worked faithfully and I do not experience the bug reported herein with the other PCs connected to the same KVMS.

The PC experiencing the crash is called testbox3, which runs Devuan Chimaera and vbox 7.0.10. There is another called testbox1. (There is no testbox2 atm.) testbox3 runs 2 VMs, one a Devuan Chimaera with all the latest patches and kernel, and the vbox guest additions 7.0.10. The other VM, which is running openwrt, does not crash.

When I use the KVMS to switch away from testbox3 to another PC connected to the KVMS, there is consistently a crash of the Devuan VM (but not the openwrt VM). But this will only happen consistently until some undetermined change occurs, perhaps related to rebooting testbox3; I have observed that rebooting the hardware can sometimes reset this problem and the crashes go away. But while the hardware or system--whatever it is that is at fault--is crashing the VM, it does so consistently, at least until a reboot (and even then, there is no guarantee that a reboot will reset things). It is not sporadic when the environment is in this state. I wish I could explain this more concisely.

It is almost as if the PC goes through an illness for a while, and while this flareup persists (whatever is causing it, idk) I will experience the crashes. Once the illness is cleared (again, not sure what causes it to clear up), the problem goes away and this symptom does not happen, at least not until the next flare-up of the illness (again, whatever that is).

All of the PCs connected to the KVMS have similar hardware configurations. testbox3 is different mainly in that it only has 16GB of RAM, whereas the other PCs have 32GB. However, I have checked and I see that testbox3 is not maxing out on memory.

Another difference is that testbox3 has a Athlon II X6 (thuban) processor, whereas the others have FX8350s.

All of the PCs are wired together via ethernet PCI interfaces. They all pass through a dumb Netgear switch. I have set up UDP Tunneling to achieve complete network connectivity; however, even before I implemented UDP Tunneling, I was observing this crash problem.

(Note: Apologies if this is TMI, but I am trying to do my best to describe the environment.)

I am attaching several files.

[systemdlete]

Hardware listing for testbox3 vbox host

[systemdlete]

stack traceback of crash. The core file itself is too large to upload here. gdb /usr/lib/virtualbox/VirtualBoxVM tempsys core

[systemdlete]

VM configuration for tempsys, the VM that is crashing

[systemdlete]

host virtualbox configuration

[systemdlete]

tempsys VM log. This is the ENTIRE log; I have checked and double-checked this, honestly!

[systemdlete]

Nominally speaking, testbox3 works and is stable. However, I have noticed that sometimes it seems like the host and tempsys cannot talk to the openwrt VM. It was not working yesterday, for instance; running tcpdump/wireshark on the host and tracing the NICs of the VMs as well as on the guest's interfaces internally, I noticed that tempsys and the host were trying to send ethernet packets, but they could not reach any other system on the entire network. This was strange, because ARP was working as expected and resolving hosts that testbox3 was trying to ping. It just could not or would not complete sending the packets to VMs. Similar behavior was observed in tempsys.

But then something completely odd occurred. I decided to leave this issue for the morning. When I woke up and returned to testbox3, this issue with not being able to ping had magically sorted itself out. Unless I have been sleepwalking, I cannot state that I intentionally modified anything on testbox3 between leaving it and returning to it.

Since that mysterious occurrence, I have rebooted testbox3 several times, and the network continues to work as expected. It seems stable and trouble-free, as does the rest of my network. I only bring this up because I wonder if this might, in some whacky way-out sort of way, be related to this bug ticket. I sort of doubt it, but perhaps engineers may be able to explain it.

I have also shut down testbox3 and run memtest 6.20 on the entire memory, full test. It passed without any issues. I have checked through system logs on all of the hosts connected to the KVMS and do not notice anything unusual.

[systemdlete]

Here's a little more info, when launching the VM from the command line:

# time VirtualBoxVM --startvm tempsys Qt WARNING: xcb_shm_create_segment() can't be called for size 7488215624, maximumallowed size is 4294967295 Segmentation fault (core dumped)

real 0m52.870s user 0m3.198s sys 0m26.907s #

[fth0]

Subscribing to the ticket by giving a meaningful comment: ;)

FWIW, the backtrace ends with "memmove_sse2_unaligned_erms()", which looks like a CPU capability dependent memmove() variant. But according to the VBox.log file, host and guest are supposed to have the SSE2 capability.

@systemdlete: Does it make a difference if you set General > Basic > Version to Debian (64-bit)?

[systemdlete]

fth0: Once again, thank you for the help.

All of my Devuan VMs on all of my systems were set to Debian 64 except tempsys. Good catch, but it didn't help. I tried both Debian 64 and Debian Bullseye, but the crash persists.

I can provide the entire core dump file even though it is close to 8GB. I have uploaded it to my mega account and I can share out the core file; I have even created a sha512sum file for it to ensure safe transfer. I don't know if it others would feel safe to download it, but I am offering it if anyone needs that level of detail.

[systemdlete]

I decided to reset the entire hardware. I first ran memtest86, which passed. Then I ran badblocks on the entire disk, just to make sure the problem wasn't with the disk. It also passed. Then I re-installed the host operating system from scratch, re-installed vbox, recreated the VMs, etc. I wanted to try everything I could think of to eliminate hardware and environmental causes.

The crash persisted after all this effort... although at some point, and again, not sure why, it stopped the crashing.