VirtualBox

Ticket #11351 (closed defect: fixed)

Opened 7 years ago

Last modified 4 years ago

linux guest often aborts when opening MacBookPro lid

Reported by: Chris Westin Owned by:
Component: other Version: VirtualBox 4.2.6
Keywords: abort, resume Cc: cwestin@…
Guest type: Linux Host type: Mac OS X

Description

Fedora 16 guest running on OSX 10.8.2 host.

Up until recently, I was running Virtual Box 4.1.18. I leave my Fedora Guest running all the time, including across MacBookPro lid opening/closing. Guest additions are installed. Never had a problem.

A few days ago, I upgraded to 4.2.6. I upgraded all packages in the guest (via yum upgrade), and the guest additions. Now, about every other time I open my MacBook lid, the guest has aborted.

Most recent log attached, but I don't see anything obvious in it.

Attachments

fedora-16-jetty-2012-12-30-16-49-39.log Download (68.2 KB) - added by Chris Westin 7 years ago.
most recent virtual box log

Change History

Changed 7 years ago by Chris Westin

most recent virtual box log

comment:1 Changed 7 years ago by RichardBarran

I have noticed exactly the same bug. Here is my setup:

  • MacBook Pro 13" mid-2009, Intel Core 2 duo @ 2.26Ghz, upgraded to 8GB ram and a Corsair SSD. Runs OSX 10.8.2.
  • Guest is Ubuntu 12.04 (server install only, i.e. no GUI).
  • Connection to the guest is by ssh and by FUSE.
  • Everything is up-to-date.

Like Chris I see the guest crashing very often when the mac goes to sleep (at first I thought it was only when I closed the lid, so I started leaving the lid up and putting the machine to sleep manually, and got the same crash). Happy to supply more information if you tell me what you need!

comment:2 Changed 7 years ago by JohnAGonzalez

I am getting the same thing on my MacBook Pro. Here is my setup:

  • MacBook Pro 15" Mid-2009 Intel Core 2 Duo @ 2.66GHz, 8GB Ram, 1TB HDD
  • OSX 10.8.2 (Mountain Lion)
  • Guest: Windows XP Pro SP3, 1GB RAM, 100Gb VHD

I noticed tonight that the VM was paused due to putting the Mac to sleep (normal), but when I opened the lid, the VM was on the screen for about 30 seconds and then just disappeared. I looked for the VBOX.log file, but the most recent one is from November.

I have the computer set to go to sleep at night and there are occasions where the VM is not running in the morning. There are also times when I am traveling in town and open up the lid to find that the VM is just gone. The VBoxManager window shows that the status of that VM is "Aborted". Let me know if there is anything else that you require and I'll gladly get what I can.

Thanks.

comment:3 Changed 6 years ago by jedlin

I too am experiencing this bug. Setup:

  • Macbook Pro 15" mid-2011
  • os x 10.8.2
  • vbox 4.2.6 r82870

Guest: Win 7 1gb ram 100gb vhd

comment:4 Changed 6 years ago by bgarns

I too am experiencing this bug. Here's my setup:

Host

  • MacBook Pro 17" mid-2010, 2.66 GHz Intel Core i7
  • 8 GB RAM
  • OS X 10.8.2
  • VirtualBox 4.2.6 r82870

Guest

  • Windows 7
  • 2 GB RAM
  • 100 GB SATA
  • 45 MB Video Memory, 2D Video
  • Audio: CoreAudio, Intel HD Audio
  • Network: Intel PRO/1000MT Desktop (NAT)

comment:5 Changed 6 years ago by ion

I also ran into this bug since upgrading to 4.2.6, same behavior as described above: guest aborts when host resumes from sleep (not always, but most of the times). Upgrading to 4.2.8 did not fix it.

Host:

  • MaxBook Pro 15 Mid-2010
  • 2.4 Ghz Intel Core i5
  • 8Gb RAM
  • OSX 10.8.2 (Mountain Lion)
  • VirtualBox 4.2.8

Guest

  • Centos 6
  • 1515MB RAM
  • 2 CPU
  • 34.18 GB SATA
  • 2x NIC (NAT + Host Only) Intel Pro/1000 MT
  • 1 Shared Folder
  • Guest Additions Installed
  • No snapshots

More info available on request.

comment:6 follow-up: ↓ 7 Changed 6 years ago by frank

This might be a duplicate of #11444.

comment:7 in reply to: ↑ 6 ; follow-up: ↓ 8 Changed 6 years ago by ion

Replying to frank:

This might be a duplicate of #11444.

How could I confirm this? Is there a way to reproduce this to confirm the same root cause? In the log, I only found lines related to suspending the guest; nothing related to resuming:


00:21:47.957571 Changing the VM state from 'RUNNING' to 'SUSPENDING'.

00:21:47.968635 AIOMgr: Endpoint for file '/Users/ionut/VirtualBox VMs/Centos 6 Clone/Centos 6 Clone.vdi' (flags 000c0781) created successfully

00:21:48.004596 PDMR3Suspend: 40 816 094 ns run time

00:21:48.004625 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'.


comment:8 in reply to: ↑ 7 Changed 6 years ago by ion

Replying to ion:

Replying to frank:

This might be a duplicate of #11444.

How could I confirm this? Is there a way to reproduce this to confirm the same root cause? In the log, I only found lines related to suspending the guest; nothing related to resuming:


00:21:47.957571 Changing the VM state from 'RUNNING' to 'SUSPENDING'.

00:21:47.968635 AIOMgr: Endpoint for file '/Users/ionut/VirtualBox VMs/Centos 6 Clone/Centos 6 Clone.vdi' (flags 000c0781) created successfully

00:21:48.004596 PDMR3Suspend: 40 816 094 ns run time

00:21:48.004625 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'.


Apologies; I found the crash report and it seems similar to the one reported in #11444:

Crashed Thread:  4  TIMER

Exception Type:  EXC_ARITHMETIC (SIGFPE)
Exception Codes: EXC_I386_DIV (divide by zero)
.......
Thread 4 Crashed:: TIMER
0   VBoxC.dylib                         0x0000000108d4617b 0x108cab000 + 635259
1   VBoxRT.dylib                        0x00000001002737ba RTTimerLRDestroy + 442
2   VBoxRT.dylib                        0x00000001002409df RTThreadCreateF + 271
3   VBoxRT.dylib                        0x00000001002930fc RTThreadPoke + 540
4   libsystem_c.dylib                   0x00007fff8cd32742 _pthread_start + 327
5   libsystem_c.dylib                   0x00007fff8cd1f181 thread_start + 13

Thanks!

For the others wishing to confirm they experience the same issue (#11444): check the "/Library/Logs/DiagnosticReports/VirtualBoxVM_*" VirtualBox crash log - should resemble the pattern above.

comment:9 Changed 6 years ago by JohnAGonzalez

Thanks ion! I had a VM crash this morning when I woke the computer up from sleep. I found the crash report in the location that you specified and it is similar in content to the sample that you posted.

comment:10 Changed 6 years ago by frank

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

Please reopen if this still happens with VBox 4.2.10.

comment:11 Changed 4 years ago by mike.marcacci

Hey all, I've recently seen a regression on this issue while running 4.3.22.

Here's the truncated crash log of one such crash, please let me know if there's anything more you need. Because this is likely a different cause for the same symptom, I'll leave this ticket closed and leave it to your discretion whether a new issue should be created, or this one reopened.

Thanks!

Mike

Process:               VBoxHeadless [54014]
Path:                  /Applications/VirtualBox.app/Contents/MacOS/VBoxHeadless
Identifier:            VBoxHeadless
Version:               ???
Code Type:             X86-64 (Native)
Parent Process:        VBoxSVC [53957]
Responsible:           Terminal [357]
User ID:               501

Date/Time:             2015-02-25 11:03:17.964 -0800
OS Version:            Mac OS X 10.10.2 (14C109)
Report Version:        11
Anonymous UUID:        B2BF7B95-BBED-7F72-302F-84B31BCE5631

Sleep/Wake UUID:       2F365218-CC81-4C49-A0F0-F793C0FB0E98

Time Awake Since Boot: 110000 seconds
Time Since Wake:       5 seconds

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
--> 
    __TEXT                 0000000100000000-0000000100008000 [   32K] r-x/rwx SM=COW  /Applications/VirtualBox.app/Contents/MacOS/VBoxHeadless

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   VBoxDD.dylib                  	0x00000001090f2cf8 ExplicitlyLoadVBoxSVGA3D_EndProc + 377418
1   VBoxDD.dylib                  	0x00000001090eb4ad ExplicitlyLoadVBoxSVGA3D_EndProc + 346623
2   com.apple.SystemConfiguration 	0x00007fff8c8a7892 rlsPerform + 150
3   com.apple.CoreFoundation      	0x00007fff8fedc681 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
4   com.apple.CoreFoundation      	0x00007fff8fece80d __CFRunLoopDoSources0 + 269
5   com.apple.CoreFoundation      	0x00007fff8fecde3f __CFRunLoopRun + 927
6   com.apple.CoreFoundation      	0x00007fff8fecd858 CFRunLoopRunSpecific + 296
7   VBoxHeadless.dylib            	0x0000000100080bee TrustedMain + 44270
8   VBoxHeadless.dylib            	0x0000000100080e5b TrustedMain + 44891
9   VBoxHeadless.dylib            	0x0000000100079b31 TrustedMain + 15409
10  VBoxHeadless                  	0x0000000100003d95 start + 7061
11  VBoxHeadless                  	0x0000000100002234 start + 52



...



Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x00000001008db600  rcx: 0x0000000000000000  rdx: 0x00007fff7b368070
  rdi: 0x0000000103802200  rsi: 0x0000000100016600  rbp: 0x00007fff5fbfa4e0  rsp: 0x00007fff5fbfa130
   r8: 0x0000000000000002   r9: 0x0000000101a00000  r10: 0x0000000000000030  r11: 0x0000000101a00000
  r12: 0x00000000ffffffff  r13: 0x00007fff7b368070  r14: 0x0000000101a0d210  r15: 0x0000000101912ee0
  rip: 0x00000001090f2cf8  rfl: 0x0000000000010246  cr2: 0x0000000000000000
  
Logical CPU:     6
Error Code:      0x00000004
Trap Number:     14



...




VM Region Summary:
ReadOnly portion of Libraries: Total=186.3M resident=176.3M(95%) swapped_out_or_unallocated=10.0M(5%)
Writable regions: Total=1.3G written=1.2G(88%) resident=1.2G(89%) swapped_out=24K(0%) unallocated=152.3M(11%)
 
REGION TYPE                      VIRTUAL
===========                      =======
Dispatch continuations             16.0M
IOKit                              1388K
Kernel Alloc Once                     4K
MALLOC                              1.2G
MALLOC (admin)                       32K
MALLOC_LARGE (reserved)            8704K        reserved VM address space (unallocated)
STACK GUARD                        56.1M
Stack                              18.0M
VM_ALLOCATE                        22.0M
VM_ALLOCATE (reserved)             8208K        reserved VM address space (unallocated)
__DATA                             23.4M
__IMAGE                             528K
__LINKEDIT                         71.3M
__TEXT                            115.0M
__UNICODE                           544K
shared memory                         4K
===========                      =======
TOTAL                               1.6G
TOTAL, minus reserved VM space      1.6G
Last edited 4 years ago by mike.marcacci (previous) (diff)

comment:12 Changed 4 years ago by frank

mike.marcacci, please add your comment to #13874, looks like this is the problem you see. Also, could you provide a core dump / crash dump?

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use