VirtualBox

Opened 15 years ago

Closed 8 years ago

#5649 closed defect (obsolete)

HostMemoryLow VM error for 3.5GB OpenSolaris guest on MacOS X

Reported by: Mason Lee Owned by:
Component: VMM Version: VirtualBox 3.1.0
Keywords: HostMemoryLow Cc:
Guest type: Solaris Host type: Mac OS X

Description (last modified by aeichner)

My OpenSolaris (64) guest goes into suspended state after running for several hours, seemingly due to some memory issues. The guest has 3584MB ram assigned, and is not using nearly all of that, as you can see below. Its memory usage seems stable over time. The host system, Mac OS X 10.6.2 running VBox 3.1 (btw, same problem on 3.0.10) has plenty of available RAM, and its memory usage seems stable as well. This happens to the guest running in both headless and non-headless mode.

In the guest, memory seems to be relatively stable over time:

$ top
Memory: 3584M phys mem, 1865M free mem, 512M total swap, 512M free swap

$ isainfo
amd64 i386

(Hmm. OpenSolaris not running in 64 bit mode?)

VirtualBox Log shows the following error:

03:59:48.183 PGM: Failed to procure handy pages; rc=VERR_NO_MEMORY rcAlloc=VERR_NO_MEMORY rcSeed=VINF_SUCCESS cHandyPages=0x8
03:59:48.183      cAllPages=0xe106f cPrivatePages=0xc28c1 cSharedPages=0x0 cZeroPages=0x1e7ae
03:59:48.183 PGM: Failed to procure handy pages; rc=VERR_NO_MEMORY rcAlloc=VERR_NO_MEMORY rcSeed=VINF_SUCCESS cHandyPages=0x7
03:59:48.183      cAllPages=0xe106f cPrivatePages=0xc28c2 cSharedPages=0x0 cZeroPages=0x1e7ad
03:59:48.183 VM: Raising runtime error '!HostMemoryLow' (fFlags=0x2)
03:59:48.183 Changing the VM state from 'RUNNING' to 'SUSPENDING'.
03:59:48.184 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'.
03:59:48.185 ERROR [COM]: aRC=NS_ERROR_INVALID_ARG (0x80070057) aIID={e2a38ebc-d854-4a3e-bc2e-fdf5ac4a0000} aComponent={Display}
  aText={Argument address is NULL} aWarning=false, preserve=true
03:59:48.185 Console: VM runtime error: fatal=false, errorID=!HostMemoryLow message="Unable to allocate and lock memory. The
virtual machine will be paused. Please close applications to free up memory or close the VM"

If I resume the machine, the same error is repeated and the machine goes into aborted state.

Ideas or advice as to how to further isolate the problem? Thanks!

Attachments (7)

VBox.log (45.3 KB ) - added by Mason Lee 15 years ago.
Log file for problem described in ticket 5649
Ticket5649SecondLog.log (48.3 KB ) - added by Mason Lee 15 years ago.
Same vm, RAM now at 3GB, goes to "Aborted" after a few days. No error in log.
VBox.2.log (41.5 KB ) - added by Frank Mehnert 15 years ago.
buffyg VBox.log
crashreport (40.9 KB ) - added by Frank Mehnert 15 years ago.
buffyg crashreport
vmstat (497 bytes ) - added by Frank Mehnert 15 years ago.
buffyg vmstat
ulimita (495 bytes ) - added by Frank Mehnert 15 years ago.
buffyg ulimita
system.log.2060 (3.3 KB ) - added by Bayard Bell 15 years ago.
entries from system.log

Download all attachments as: .zip

Change History (25)

comment:1 by Frank Mehnert, 15 years ago

Description: modified (diff)

Please attach the whole VBox.log file, not only a part of it (use the Attach button please).

by Mason Lee, 15 years ago

Attachment: VBox.log added

Log file for problem described in ticket 5649

comment:2 by Mason Lee, 15 years ago

Hi Frank, I attached the log. I believe it shows the crashes after the machine puts itself in a paused state and I attempt to resume.

By the way, after submitting this ticket, I set the guest RAM down to 3078MB and have not yet seen this problem recur.

by Mason Lee, 15 years ago

Attachment: Ticket5649SecondLog.log added

Same vm, RAM now at 3GB, goes to "Aborted" after a few days. No error in log.

comment:3 by Mason Lee, 15 years ago

I've added a new log file. I've now seen this guest move to "aborted" state twice. It's the same image as before but now with only 3GB ram. The abort happens (both times) after about a week. I don't know if this new behavior is related to the issue on this ticket, but I thought I should add the info just in case. There's no error printed to the log when the machine aborts (unlike in the first log at 3.5GB ram). I've attached the latest log from the aborted machine.

I may have had the VM set to be 32GB originally--can't remember. It is definitely a 64 bit open solaris guest now, though. The guest OS image is snv-111b. I have several other vbox solaris guests running 24/7 on this same host machine with the same basic configs but with only 2GB ram, and they don't crash or abort (yet). Only the one with 3GB crashes after a week.

Let me know if there's any more info or tests I can provide. Thanks!

comment:4 by Mason Lee, 15 years ago

Hm, one difference-- my other non-crashing guest machines have USB disabled in vbox settings. I'm not doing anything with the usb intentionally, however. Just disabled it.

comment:5 by Sander van Leeuwen, 15 years ago

The last log implies a crash of the VM process. A core dump might be helpful in that case.

comment:6 by Mason Lee, 15 years ago

Hi, I've been running the VM for a few weeks now with "ulimit -c unlimited" to see about getting a core dump, but it hasn't crashed again yet. Clever gremlins. I'll keep you posted. Thanks.

comment:7 by Bayard Bell, 15 years ago

I've got a problem whereby I can't allocate 3GB or more (let alone an allocation over the 32-bit application limit) in Mac OS X 10.5.8 running 3.1.14. Although this is a 32-bit kernel, even allocations that should be possible under 32-bit memory sizes fail.

by Frank Mehnert, 15 years ago

Attachment: VBox.2.log added

buffyg VBox.log

by Frank Mehnert, 15 years ago

Attachment: crashreport added

buffyg crashreport

by Frank Mehnert, 15 years ago

Attachment: vmstat added

buffyg vmstat

by Frank Mehnert, 15 years ago

Attachment: ulimita added

buffyg ulimita

comment:8 by Frank Mehnert, 15 years ago

Sigh, I've removed your pasted log files. Can you tell me what else I can do to prevent people from pasting log files into the ticket? There are bug fat warnings at several places.

comment:9 by Bayard Bell, 15 years ago

Sorry, I'm sure that there are places where advice is given about how to post debug data, but I managed not to read the "Please NEVER paste log files here!" in trying to update the ticket. I don't interact with the ticketing system regularly, but for whatever reason I imagine everything is going swimmingly if I seem to be able to do things the way I intuit I should be able, meaning that I don't backtrack to read instructions, particularly those which aren't visually distinct from other text on the page above the point where I'm editing. Assuming your question isn't entirely rhetorical, I'd suggest that some modest change to make the directive stand out, like using a sharply distinguished colour, might draw attention to it, as drawing attention to it will help people preserve your productivity and sanity. As it is, the only text that pulls my eyes over is the separate colour used for the WikiFormatting link.

comment:10 by Frank Mehnert, 15 years ago

Done.

by Bayard Bell, 15 years ago

Attachment: system.log.2060 added

entries from system.log

comment:11 by Bayard Bell, 15 years ago

The instructions are unmistakable in their demand for attention. Vielen Dank für ihre Geduld.

I've got a core file as well, but it doesn't seem to want to upload, perhaps because of its size (3.6 GB). What's the best way to get this over to you?

comment:12 by paradigm, 14 years ago

I have the same problem with a Windows 7 64 bit host in snow leopard.

comment:13 by Frank Mehnert, 14 years ago

Component: otherVMM

comment:14 by Wolfgang Glas, 14 years ago

I've had the same problem here when running a debian squeeze amd64 virtual machine with 3GB under MacOSX 10.6.6.

Although my machine is running under 64bit all virtualbox binaries in /Applications/VIrtualbox.app/Contents/MacOS are 32bit binaries. The HostMemoryLow error occurs, when the "VirtualBox VM" process reaches the 3GB limit as seen by MacOSX. It is quite normal, that 32bit apps cannot allocate more than 3GB, because the address space of an executable must reserver some address ranges for things other than the heap.

I tried to run the *-amd64 counterparts of the 32bit binaries, which are delivered alongside the 32bit binaries in /Applications/VIrtualbox.app/Contents/MacOS, but I had no success. Even when I start the GUI using 'Virtualbox-amd64' , the virtual machine itself is started as a 32bit binary.

Is there any official advice on how to set up a clean 64bit installation of VirtualBox under MacOSX?

Best regards and TIA,

Wolfgang

comment:15 by Wolfgang Glas, 14 years ago

OK, I finally found out, that I had to turn on the 64bit kernel mode MacOSX 10.6 like described under

http://ahatfullofsky.comuv.com/English/Programs/SMS/SMS.html

and now the 64 bit binaries start like a charm. The findings from this bug report are, that under 32bit MacOSX it is not advisable to run Virtual Machines with 3-3.5GB or more.

Best regards, Wolfgang

comment:16 by Mason Lee, 14 years ago

I appreciate your posting, Wolfgang! Very much, Mason

comment:17 by Wolfgang Glas, 14 years ago

From my point of view, this issues should be closed and the documentation should be updated in order to contain a hint on the 32bit vs. 64bit kernel mode.

The VM configuration dialog should also recommend to not configure more than 2.5GB under 32bit MacOSX. For virtual machines with more virtual memory a warning should be issued to the user or the slider should be in the "orange" or "red" region.

Currently, the VM config dialog lets me configure 3.5GB of RAM in 32 bit kernel mode and up to 6GB in 64bit kernel mode on my 8GB MacBook Pro.

Best regards, Wolfgang

comment:18 by aeichner, 8 years ago

Description: modified (diff)
Resolution: obsolete
Status: newclosed

Obsolete for recent VirtualBox releases sa we don't support 32bit OS X hosts anymore, closing.

Note: See TracTickets for help on using tickets.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette