HostMemoryLow VM error for 3.5GB OpenSolaris guest on MacOS X

[Mason Lee]

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!

[Frank Mehnert]

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

[Mason Lee]

Log file for problem described in ticket 5649

[Mason Lee]

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.

[Mason Lee]

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

[Mason Lee]

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!

[Mason Lee]

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.

[Sander van Leeuwen]

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

[Mason Lee]

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.

[Bayard Bell]

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.

[Frank Mehnert]

buffyg VBox.log

[Frank Mehnert]

buffyg crashreport

[Frank Mehnert]

buffyg vmstat

[Frank Mehnert]

buffyg ulimita

[Frank Mehnert]

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.

[Bayard Bell]

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.

[Frank Mehnert]

Done.

[Bayard Bell]

entries from system.log

[Bayard Bell]

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?

[paradigm]

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

[Wolfgang Glas]

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

[Wolfgang Glas]

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

[Mason Lee]

I appreciate your posting, Wolfgang! Very much, Mason

[Wolfgang Glas]

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

[aeichner]

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