consistent memory allocation/lock error Ubuntu install

[ljwobker]

I'm consistently able to reproduce an issue where the guest throws the dreaded "unable to allocate and lock memory" error.

It happens when I build a 4GB VM and then try to install 64b Ubuntu 14.04 via the .iso. A few choices into the install menu, it throws the memory error, pauses/kills the VM, and hangs. This happens every time. Oddly enough I can workaround this by reducing the amount of memory assigned to the VM to 2GB. Once reduced, the guest OS installs without error, and then (this is a little odd) I can go back into settings and increase the amount of memory back to 4GB and it runs fine.

The host machine is running windows 7, has 12GB of physical memory installed and has upwards of 9GB free when I try to run the VM/install process. I've killed every running process I can get my hands on so I'm very confident it's not an actual memory availability issue.

Thoughts? Iv'e attached the log file in case that helps.

[mpack]

I'm very confident it's not an actual memory availability issue.

I'm not sure what that confidence is based on. Memory allocation is a well tested part of VirtualBox: if it reports a memory allocation error then you should believe it.

I'm not sure, but I think the allocated memory has to be contiguous, which is obviously more likely to cause problems if you try to allocate too large a chunk of your available RAM. However for this to be a problem there would have to be something else using fixed memory somewhere in the middle of the address space... but I have no idea how to diagnose that more. Typically the fixed memory user would be a driver of some kind, and I'm guessing it's currently getting loaded after some other huge memory hog which later unloads.

[ljwobker]

I absolutely hear what you're saying, which is why it seems so strange.
And I said I was confident it wasn't an availability issue - independent of that memory being contiguous or not. I know very little about windows memory management, but when a system has 10GB of free memory it seems odd that an application couldn't get 4GB of that. It also seems even more odd that any app would require a contiguous block that large - surely the virtualbox stuff does not require the whole VM to be a single block(!!?!)

And there's nothing in Ubuntu anywhere that tries to grab that much memory - because the whole system can run comfortably in less than a gig - certainly the installer can.

[mpack]

It also seems even more odd that any app would require a contiguous block that large - surely the virtualbox stuff does not require the whole VM to be a single block(!!?!)

VirtualBox has unusual requirements of that memory. It will be running device drivers inside the VM which will run at an elevated privilege level, so the memory can't be user level (paged) ring3 stuff. So your expectations for a typical application may not apply.

[ljwobker]

OK - what would be unique to the Ubuntu installation routine (where it only works if the VM is set to 2G) compared to an installed system, which reliably runs configured with 4GB?

[mpack]

That I have no idea about. The peculiar thing is that the memory allocation fails after the VM has begun to boot, i.e. after the VM has already been created and presumably after the RAM has been allocated. The exact sequence is :-

00:00:31.492769 UIFrameBufferQImage::resizeEvent: Format=843204434, BitsPerPixel=32, BytesPerLine=4096, Size=1024x768
00:00:31.492791 UIFrameBufferQImage::resizeEvent: Resizing to directly use VGA device content..
00:01:19.162298 PGM: Failed to procure handy pages; rc=VERR_NO_MEMORY rcAlloc=VINF_SUCCESS rcSeed=VINF_SUCCESS cHandyPages=0x8
00:01:19.162305 cAllPages=0x108448 cPrivatePages=0xac9c0 cSharedPages=0x0 cZeroPages=0x5ba62

Note that there's a 50 second gap between the display resize and the memory allocation error, so I assume there is no connection.

I admit I have no idea what "handy pages" might be. Perhaps something to do with nested paging? You could try turning nested paging off and see if that influences the outcome.

[Perryg]

I believe I remember an application could cause this. Google notifier or something like that ( installed on the host ).

[ljwobker]

Answering my own question... I had a small utility called "Prio" installed, and for unknown reason it was causing the problem. Once uninstalled, everything has run cleanly for weeks. Too bad, because the program itself is quite useful... ;-(

http://www.softpedia.com/get/System/OS- ... Prio.shtml

[mpack]

Well, as implied above, if you could somehow control the load order - i.e. get prio to load before whatever space hogger currently runs first on boot (Outlook?), then "prio" could be loaded lower down in memory, and locking it there wouldn't cause as much of a problem.