Opened 8 years ago
Closed 8 years ago
#16001 closed defect (duplicate)
segfault while deleting a snapshot on a VM with two virtual hard drives
| Reported by: | js | Owned by: | |
|---|---|---|---|
| Component: | virtual disk | Version: | VirtualBox 5.1.6 |
| Keywords: | snapshot | Cc: | |
| Guest type: | Windows | Host type: | Linux |
Description
I am using VirtualBox (from the Debian repositories - their maintainer asked me to open a ticket here, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838766) for virtualisation. One of my VMs uses two virtual hard drives (Fixed-size VDIs of 120 GBytes each, visible to the guest as SATA drives). I am trying to delete the oldest snapshot on this VM, so the "original" (fixed-size) VDI files are to be modified as changes are merged back into them from the oldest "difference" VDIs. Snapshot deletion was triggered using the "delete snaphot" button in the QT GUI; the host system was freshly booted, and no VMs were running. VirtualBox merges the "difference" VDI back into the first fixed-size VDI. It then deletes the "difference" VDI from the host filesystem, but instead of working on the second virtual disk, the progress indicator just disappears. The snapshot is still visible; the Virtual media Manager lists the "difference" VDI that was just being deleted as "missing" (so obviously, the media registry was not updated). dmesg delivers the message "[ 868.272600] DeleteSnap[2018]: segfault at 31 ip 000000000052bf8c sp 00007fb4b7b6d9c0 error 4 in VBoxSVC[400000+482000]" (the precediung and following lines are not associated with VirtualBox). I have no hints of physical media errors in the kernel log, so I consider the hard drive as OK here. htop shows that I am now having a total of three active VirtualBox processes, which load two physical CPU cores at 100% each.
The expected behaviour would have been that nothing crashes, the VirtualBox media registry is updated correctly, and the second virtual disk is processed as well. Then, the configuration file for this VM shall be updated according to the snapshot deletion, and the snapshot shall disappear from the snapshot tree.
I restored the VM from a backup and tried again, with the same result (however, I did not check dmesg and htop in the 2nd attempt).
The last time I deleted snapshots for this VM was with VirtualBox 5.0.24; I did not have trouble there. VirtualBox 5.1.6 now shows the described behaviour.
I have no problems with deleting snapshots for VMs that have only one virtual hard drive in VirtualBox 5.1.6, so this seems to be linked to the number of virtual drives.
This seems to be a duplicate of #15831: "vm state corupted because failed snapshot deletion". It also triggers with two or more HDs attached to the VM.