Ticket #16745 (closed defect: fixed)

Opened 2 years ago

Last modified 2 years ago

Segmentation fault while starting a VM headless from snapshot

Reported by: bb90 Owned by:
Component: VM control Version: VirtualBox 5.1.22
Keywords: segfault snapshot headless Cc:
Guest type: Linux Host type: Linux

Description (last modified by frank) (diff)

Given a newly created Ubuntu VM installed with Cloud-Init And a snapshot from the VM When I restore the snapshot (VBoxManage snapshot server restorecurrent --> no problem) And start the VM (VBoxManage startvm server --type headless)

Then I get 'VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component SessionMachine, interface ISession' And there is segfault log in syslog (attached).

Ubuntu 16.04.2 LTS (Xenial Xerus)
Linux HOST 4.8.0-49-generic #52~16.04.1-Ubuntu SMP Thu Apr 20 10:55:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

There is also some path mismatch. Snapshot file is here: /home/USER/VirtualBox VMs/GROUP/server/Snapshots/{b60bca32-76e8-4815-88cd-e55516a6186a}.vdi VBox wants: /home/USER/VirtualBox VMs/GROUP/server/Snapshots/2017-05-09T09-32-52-131952000Z.sav/Snapshots/2017-05-09T09-32-52-131952000Z.sav

Please fix this issue. For now, I have to revert the VirtualBox version to older, working one.


syslog.txt Download (1.2 KB) - added by bb90 2 years ago.
vbox.log Download (1.1 KB) - added by bb90 2 years ago.

Change History

Changed 2 years ago by bb90

Changed 2 years ago by bb90

comment:1 Changed 2 years ago by bb90


VBoxManage unregistervm --delete server
Progress state: VBOX_E_IPRT_ERROR
VBoxManage: error: Machine delete failed
VBoxManage: error: Could not delete file '/home/USER/VirtualBox VMs/GROUP/server/Snapshots/2017-05-09T09-32-52-131952000Z.sav/Snapshots/2017-05-09T09-32-52-131952000Z.sav'(VERR_FILE_NOT_FOUND)
VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component MachineWrap, interface IMachine
VBoxManage: error: Context: "RTEXITCODE handleUnregisterVM(HandlerArg*)" at line 163 of file VBoxManageMisc.cpp
Last edited 2 years ago by frank (previous) (diff)

comment:2 Changed 2 years ago by bb90

Work around: if the newly created VM is not moved to a VM group. Than the problem does not occur. Maybe the .sav file is not moved with the VM.

comment:3 Changed 2 years ago by frank

Would be interesting to know which older, working version of VirtualBox you are referring to.

comment:4 Changed 2 years ago by frank

  • Description modified (diff)

Furthermore I would like to have a step-by-step reproduction scenario for the problem triggered with VBox 5.1.22.

comment:5 Changed 2 years ago by bb90

Hi frank,
I have tried 5.0 (ubuntu xenial virtualbox package), but it also was not working.

Here is a was to reproduce it. It "works" 100% for me.

curl -o /tmp/ubuntu.img
qemu-img convert -O vdi /tmp/ubuntu.img /tmp/ubuntu.vdi
VBoxManage internalcommands sethduuid /tmp/ubuntu.vdi
VBoxManage createvm --name tst --register
VBoxManage modifyvm tst  --cpus 1  --memory 256  --boot1 disk --boot2 none --boot3 none --boot4 none  --nic1 nat  --cableconnected1 on  --ostype Linux_64  --ioapic on  --defaultfrontend headless
VBoxManage storagectl tst --name SATA --add sata --portcount 1 --hostiocache on[[BR]]
VBoxManage storageattach tst  --storagectl SATA --port 0 --device 0  --type hdd --medium /tmp/ubuntu.vdi
VBoxManage startvm --type headless tst
sleep 20
VBoxManage controlvm tst savestate
VBoxManage snapshot tst take 'system-initial'


  • Right click on tst VM -> group
  • snapshots -> restore to system-initial (do not create new snapshot)
  • start the tst VM in headless mode
  • It should crash, VM state should be Aborted.
VBoxManage unregistervm --delete tst

Throws error, files should be deleted manually...

My theory: after grupping the VM, the *.sav file is gone...

Last edited 2 years ago by frank (previous) (diff)

comment:6 Changed 2 years ago by frank

Thanks for the reproduction scenario. Actually it's not necessary to attach a disk to the VM. An empty VM shows the same problem. You are right, the problem comes from moving the VM into a group. That operation will wrongly update the path to the state file. The VBoxHeadless crash is another problem: It shouldn't crash if the state file cannot be found, it should just normally terminate. The second problem is easy to fix, the first problem (wrong path to the state file when groups are involved) is a bit more complicated.

comment:7 Changed 2 years ago by frank

Finally found and fixed. The fix will be part of VBox 5.1.24. The most recent 5.1.x test builds (>=115382) contain the fix as well.

comment:8 Changed 2 years ago by bb90

Hi frank, Thank you very much!

comment:9 Changed 2 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

Fix is part of 5.1.24.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use