search

jatpat / omaha

Automatically exported from code.google.com/p/omaha
Apache License 2.0
0 stars 0 forks source link

GoogleCrashHandler64 process causes 64-bit Virtualbox VMs to throw a "HostMemoryLow" error #38

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

1.Be Running Windows 7 SP1 (64-bit) 
2.Be running Omaha/Google Update 1.3.21.99
3.Be running Virtualbox 4.1.8 http://goo.gl/ZqUuv
4.GoogleCrashHandler64.exe is running
5.Create a new 64-bit Virtualbox VM instance and install a 64-bit guest OS (Win 
8 Consumer preview/Ubuntu 11.10 etc). Alternatively launch an existing 64-bit 
guest OS.

What is the expected output? 
To begin loading the 64-bit guest OS or launching of an existing 64-bit guest OS

What do you see instead?
The VirtualBox VM throws a "HostMemoryLow" error son after launch and exits

What version of the product are you using? On what operating system?
Omaha/Google Update 1.3.21.99
Virtualbox 4.1.8
Windows 7 SP1 x64

Additional information:
If GoogleCrashHandler64.exe is terminated, VMs launch with no issues.
Please refer to http://code.google.com/p/chromium/issues/detail?id=114021 for 
more detail and further user confirmation of the problem/workaround.

Duncan

Original issue reported on code.google.com by wyd...@gmail.com on 7 Mar 2012 at 2:11

Attachments:

GoogleCodeExporter commented 9 years ago 
Just to add, this is dependent on the memory assigned to the VM. For example, 
on my 8Gb Windows 7 host running only Outlook, a browser or two and VirtualBox: 
a 3Gb VM works OK but a 3.5Gb VM will report the HostMemoryLow problem within a 
few minutes of using it. As reported above, killing GoogleCrashHandler64 (or 
turning off "Automatically send usage statistics and crash reports to Google" 
in Chrome) resolves the issue.

Original comment by dhagu...@googlemail.com on 7 Mar 2012 at 9:02

GoogleCodeExporter commented 9 years ago 
Managed to get a repro on my end, but I'm not sure that this is a bug in the 
crash handler.  The tail from the VBox log reads:

00:01:14.394 PGM: Failed to procure handy pages; rc=VERR_NO_MEMORY 
rcAlloc=VINF_SUCCESS rcSeed=VINF_SUCCESS cHandyPages=0x8
00:01:14.394      cAllPages=0x104447 cPrivatePages=0xdedb9 cSharedPages=0x0 
cZeroPages=0x25669
00:01:14.394 GMM: Statistics:
00:01:14.394      Allocated pages: da9bd
00:01:14.394      Maximum   pages: 10009e
00:01:14.394      Ballooned pages: 0
00:01:14.395 PGM: Failed to procure handy pages; rc=VERR_NO_MEMORY 
rcAlloc=VINF_SUCCESS rcSeed=VINF_SUCCESS cHandyPages=0x7
00:01:14.395      cAllPages=0x104447 cPrivatePages=0xdedba cSharedPages=0x0 
cZeroPages=0x25668
00:01:14.395 GMM: Statistics:
00:01:14.395      Allocated pages: da9bd
00:01:14.395      Maximum   pages: 10009e
00:01:14.395      Ballooned pages: 0

It sounds like VBox is having more generic problems with acquiring large memory 
blocks.  No record of any attachments or other activity from the crash handler 
while it's running, and memory usage by the crash handler is staying steady at 
around 2MB.

I'll experiment a bit and see if I can figure out what's going on, but I 
suspect that this is a bug in VBox.

Original comment by ryanmyers@google.com on 7 Mar 2012 at 8:40

GoogleCodeExporter commented 9 years ago 
Found the root cause.  This will be fixed in .111.

Original comment by ryanmyers@google.com on 7 Mar 2012 at 9:31

GoogleCodeExporter commented 9 years ago 
Good work and prompt response as always Ryan, many thanks!
So not a VBox issue then? Care to divulge? ;)

Original comment by wyd...@gmail.com on 8 Mar 2012 at 2:08

GoogleCodeExporter commented 9 years ago 
It wasn't a VBox issue.

We had a bug (an unintended typecast) in a routine calling 
SetProcessWorkingSetSize() which caused us to request more working set than 
actually needed.  Windows largely ignores that setting with respect to normal 
memory allocation, so the vast majority of programs out there weren't affected.

However, for processes such as VM hosts that need to lock big chunks of memory, 
there is contention for working set, as calling SPWSS() is a prerequisite to 
calling VirtualLock() and Windows hands it out first-come-first-serve.

Original comment by ryanmyers@google.com on 8 Mar 2012 at 6:09

GoogleCodeExporter commented 9 years ago 
Thanks Ryan. .111 close on the horizon then? I'm just wondering as we use 
VMWare workstation at work, and I'm guessing it too might suffer the same 
problem.  Thanks.

Original comment by wyd...@gmail.com on 10 Mar 2012 at 4:09

GoogleCodeExporter commented 9 years ago 
Probably end of March at the latest.

Original comment by ryanmyers@google.com on 12 Mar 2012 at 5:26

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Fixed on Google Chrome 19.0.1077.3 dev-m Windows 7 Pro SP1 x64.

Today Chrome's update module has been updated to version 1.3.21.111. An issue 
has been solved for me, VMware Player 4.0.2 is able to allocate 3072 MB RAM 
memory to virtual guest machine.

Original comment by michel.b...@gmail.com on 24 Mar 2012 at 2:13

GoogleCodeExporter commented 9 years ago 
.111 works a charm, thanks Ryan!

Original comment by wyd...@gmail.com on 25 Mar 2012 at 9:15

GoogleCodeExporter commented 9 years ago

Original comment by ryanmyers@google.com on 27 Mar 2012 at 8:23