VirtualBox

Ticket #3673 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

Crash on VERR_EM_NO_MEMORY

Reported by: CaptainFlint Owned by:
Priority: major Component: other
Version: VirtualBox 2.2.0 Keywords:
Cc: Guest type: other
Host type: Windows

Description

VB 2.2.0 does not process VERR_EM_NO_MEMORY event correctly: the VM is crashed (either via Guru Meditation, or just silently closing). In beta 2 there was Guru Meditation in this situation (and on the forum it has already been reported; though the Beta Forum is now unavailable, the same problem is also mentioned e.g.  here), in 2.2.0 final this problem remained alive.

Host OS: Vista Business SP1, XP Pro SP3
Guest OS sample log is attached (SLES 11)

Attachments

VBox.log Download (45.7 KB) - added by CaptainFlint 5 years ago.
Log file

Change History

Changed 5 years ago by CaptainFlint

Log file

comment:1 Changed 5 years ago by Nephom

I have similar issue.
reproduce step:

  1. Run AntiVirus scanning or need memory program.
  2. When Guest OS memory is fully allocate and Host OS memory is over 80% usage, this Guest OS will PAUSE to wait you release Host OS memory.
  3. If your Host memory over 80% usage, the Guest OS cannot resume.

FYI

comment:2 Changed 5 years ago by frank

Did VirtualBox 2.2.2 fix that issue for you?

comment:3 Changed 5 years ago by CaptainFlint

2 frank[BR] Sorry, I was very busy these days and forgot to check it. Well, actually, I did check it once on my Vista machine, but got very strange results: when I tried to open 2 VMs that should have taken more RAM than I had available, both started successfully, though work with the host OS became much slower because of swapping. I tried to load one more VM which itself would have needed 768 MB, and when I tried that, swapping intencity gradually increased till the computer became completely unusable, but still none of the 3 VMs gave any message about low RAM. I left it for 2 hours, but even after 2 hours passed, the host OS did not even show the Task Manager I tried to call in the very beginning of that swapping, so I just reset the machine. Since then I had no spare time to repeat the experiment. :-(

Theoretically, all the 3 VMs could fit the physical memory, because I had 2 GB of RAM, and the machines' settings were 512, 512 and 768 MB. But the host OS and its programs took already almost 1 GB of physical memory (as Process Explorer claimed), so I expected VirtualBox to fail allocating memory (as it did in 2.1.4) instead of sending everything to crazy swapping...

Next time I'll try it on WinXP machine (hopefully, in a day or two) and report the results here.

comment:4 Changed 5 years ago by frank

Thanks for this test. So at least the VMs don't crash anymore. Note that passing your VMs too much memory will make your host unresponsible eventually and sometimes you will even not be able to kill one of the VMs. As long as the host OS delivers RAM, the VBox processes should happily continue. Note that, once started, there is no heuristics which would ensure that enough memory is reserved for the host. The reason is that such a heuristics would be difficult to set up.

comment:5 Changed 5 years ago by frank

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

The crash is fixed, closing.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use