VirtualBox

Ticket #9364 (closed defect: duplicate)

Opened 3 years ago

Last modified 20 months ago

VBoxSVC crashes when restoring old snapshot.

Reported by: jguerrero Owned by:
Priority: major Component: other
Version: VirtualBox 4.1.0 Keywords: restore snapshot
Cc: Guest type: other
Host type: Mac OS X

Description (last modified by klaus) (diff)

This guest was imported into 4.1.0 from a prior version. I had created about 4 snapshots and then deleted one of the
older ones (not sure of the order here though). Then I started up the guest, did some work and decided to go back to
an older snapshot. I powered off the VM and unchecked the option to create a new snapshot. I then highlighted the
oldest snapshot and clicked the button to restore it. Apparently, VBoxSVC crashed and the GUI displayed my guest as
inaccessible. Thankfully, I was able to exit VirtualBox and restart it and find that the guest was once again accessible.

Unfortunately, I did not open this ticket soon enough. I do not see a guest log that is old enough to cover the time period
of the crash. I will upload the oldest one which at least shows some of the "then current state" (I am still on the same
"snapshot chain"). I will also upload the MacOSX crash report.

I also have another MacOSX crash report from 4.0.12 where I was also trying to restore an old snapshot. Please advise
if that would be interesting for you and I will upload it, too.

Thanks

PS: here is the stack trace of the offending thread, in case it is easier for the ticket search engine to index this ticket for

someone else's search.

Thread 14 Crashed:
0   VBoxSVC                       	0x000dd73b std::list<ComObjPtr<MediumAttachment>, std::allocator<ComObjPtr<MediumAttachment> > >::remove(ComObjPtr<MediumAttachment> const&) + 11
1   VBoxSVC                       	0x001594d6 SessionMachine::restoreSnapshotHandler(SessionMachine::RestoreSnapshotTask&) + 1158
2   VBoxSVC                       	0x0015c238 SessionMachine::RestoreSnapshotTask::handler() + 24
3   VBoxSVC                       	0x00150c48 SessionMachine::taskHandler(RTTHREADINT*, void*) + 40
4   VBoxRT.dylib                  	0x003e6fe0 rtThreadMain + 64
5   VBoxRT.dylib                  	0x00439d8e rtThreadNativeMain(void*) + 142
6   libSystem.B.dylib             	0x9a811259 _pthread_start + 345
7   libSystem.B.dylib             	0x9a8110de thread_start + 34

Attachments

VBox.log.3 copy Download (105.9 KB) - added by jguerrero 3 years ago.
Oldest log file for the crashed guest.
VBoxSVC_2011-08-01-104812_localhost.crash Download (33.1 KB) - added by jguerrero 3 years ago.
VBoxSVC.log.1 copy Download (24.7 KB) - added by jguerrero 3 years ago.
Probably log from restarting vbox after crash.
VBoxSVC.log.2 copy Download (2.9 KB) - added by jguerrero 3 years ago.
Probably log from before (or during) crash.

Change History

Changed 3 years ago by jguerrero

Oldest log file for the crashed guest.

Changed 3 years ago by jguerrero

comment:1 Changed 3 years ago by jguerrero

Just a clarification on the "imported from an earlier version" comment.
This guest was created and upgraded several times through various vbox versions.
I was having issues and was unsure if they were due to 4.1.0 or not, so I had exported
the guest a few times and re-imported it. I do not know which version did the export
that I ultimately imported from. However, my point was simply that I was expecting that
the import process will "fix up" any legacy issues with guests saved by an older version.

comment:2 Changed 3 years ago by jguerrero

I found VBoxSVC logs from before (probably during) the crash (.2 extension) and after the crash (.1 extension). Uploading.

Changed 3 years ago by jguerrero

Probably log from restarting vbox after crash.

Changed 3 years ago by jguerrero

Probably log from before (or during) crash.

comment:3 Changed 3 years ago by jguerrero

FWIW, I have just restored another old snapshot on this same VM, but this time, it did not crash.
This time, I shutdown vbox and took a backup of the xml files prior to starting vbox up again
and doing the snapshot restore.

In the prior restore that crashed, I may have had a few VMs opened concurrently and stopped and
started VMs, and created more snapshots on the fly, including saving machine state. I could not
say how many VMs were open when I tried the restore. There may not have been any open, but
it had been my practice to start and stop VMs without waiting for any of the operations to finish.
May I ask if that is a frowned upon practice?

comment:4 Changed 3 years ago by frank

Hopefully fixed in VBox 4.1.4. Please confirm.

comment:5 Changed 2 years ago by frank

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

comment:6 Changed 2 years ago by moggie

Doesn't look fixed. Running 4.1.12 on Linux (gentoo). I got fed up so recompiled virtualbox with symbols.

Single snapshot. Booted the VM briefly so it was changed, then shutdown and attempted to restore the snapshot. Segfault:

#0 std::list<ComObjPtr<MediumAttachment>, std::allocator<ComObjPtr<MediumAttachment> > >::remove (this=0x0, value=...)

at /portbuild/portage/app-emulation/virtualbox-4.1.12/work/VirtualBox-4.1.12/src/VBox/Main/src-server/MachineImpl.cpp:12926

#1 0x000000000052bd1a in SessionMachine::restoreSnapshotHandler (this=0x983550,

aTask=...) at /portbuild/portage/app-emulation/virtualbox-4.1.12/work/VirtualBox-4.1.12/src/VBox/Main/src-server/SnapshotImpl.cpp:1934

#2 0x00000000005296f9 in SessionMachine::taskHandler (pvUser=0x7f1ea8090bf0)

at /portbuild/portage/app-emulation/virtualbox-4.1.12/work/VirtualBox-4.1.12/src/VBox/Main/src-server/SnapshotImpl.cpp:1334

#3 0x00007f1ec370f13c in rtThreadMain (pThread=0x7f1ea802f630,

NativeThread=<optimized out>, pszThreadName=<optimized out>) at /portbuild/portage/app-emulation/virtualbox-4.1.12/work/VirtualBox-4.1.12/src/VBox/Runtime/common/misc/thread.cpp:703

#4 0x00007f1ec375b3ee in rtThreadNativeMain (pvArgs=0x7f1ea802f630)

at /portbuild/portage/app-emulation/virtualbox-4.1.12/work/VirtualBox-4.1.12/src/VBox/Runtime/r3/posix/thread-posix.cpp:255

#5 0x00007f1ec39d2d0c in start_thread () from /lib64/libpthread.so.0 #6 0x00007f1ec2789dbd in clone () from /lib64/libc.so.6

After continuing, the UI immediately changed the VM name to Snapshot 1, and marked the VM inaccessible. When I've seen this without gdb running, the UI pretends the snapshot was restored, but when I delete the snapshot, that's when it gets screwed up and marks the VM inaccessible.

I suspect this is the cause of many of the "inaccessible" or otherwise corrupted VM stored state bugs, for instance:

https://www.virtualbox.org/ticket/9457 https://www.virtualbox.org/ticket/9808 https://www.virtualbox.org/ticket/9843 https://www.virtualbox.org/ticket/10264 ...

Once the vm is inaccessible you have to go into the .vbox xml, and tweak all the snapshot-related settings and the mounted disk image uuid to get it to work again.

I can only imagine how painful this is for people who have complex snapshot trees and aren't willing to ditch all the snapshots.

How this isn't a blocker is beyond me. I loathe making snapshots in virtualbox because of this bug.

Version 0, edited 2 years ago by moggie (next)

comment:7 Changed 2 years ago by moggie

  • Status changed from closed to reopened
  • Resolution fixed deleted

comment:8 Changed 20 months ago by klaus

  • Status changed from reopened to closed
  • Resolution set to duplicate
  • Description modified (diff)

While this bug is older than #9604 and #10491, they're all duplicates.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use