New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 2131 link

Starred by 6 users

Issue metadata

Status: Fixed
Closed: Aug 2011

Sign in to add a comment

NaCl module load failed: Insufficient memory to load file

Reported by, Aug 3 2011

Issue description

What version of the SDK are you using?

On what operating system?

What browser are you using?
Chrome 14.0.835.15 dev (Linux i686 Ubuntu 11.04)
Chrome 14.0.835.15 dev-m (Windows XP 32bit)

What steps will reproduce the problem?
1. Build my test app (i686 debug)
2. Place nexe on server
3. connect with chrome

What is the expected output?
Working app

What do you see instead?
NaCl module load failed: Insufficient memory to load file
(Same behavior on Win32 and Linux32, I don't have any 64bit machine to test the 64bit version)

I tried too and get the same result. 

This was working correctly with SDK 0.4 and Chrome 13.


Comment 1 by, Aug 3 2011

Tested on Chromium 15.0.8430 (Ubuntu 11.04 32bit) and I have the same error.
Project Member

Comment 2 by, Aug 5 2011

Labels: -Component-SDK Component-Pepper
Could you send system/hardware information (memory, processor, etc.)? Do you see the error in the JS console or somewhere else? Does the sine wave (audio) demo work?
Labels: -Component-Pepper Component-TCB Mstone-15 CoreRuntime
Status: Available
Project Member

Comment 5 by, Aug 8 2011

Labels: -Pri-2 Pri-1
Mseaborn may be able to repro this on his 32-bit Windows system.
Getting this for every NaCl file I have tested, on Chrome 14.0.835.18 dev-m on Windows. None of the examples on the NaCl gallery or any of the demos included in the SDK work.

Slightly old netbook, Compaq Mini 110, and Windows XP.

Comment 7 by, Aug 9 2011

It happen on :
Win32 : IntelCore2 Quad (2.83GHz), 3.5GB RAM, NVIDIA Quadro NVS 290, Windows XP 32bit SP3
Linux32 : (in VirtualBox) IntelCore2 Quad (2.83GHz), 1.6GB RAM (1.6GB Swap), i686 Ubuntu 11.04

The error is in the JS console.

It happens with all examples from and all the tests I compiled myself.

The same systems where working with Chrome 13 and SDK 0.4
Project Member

Comment 8 by, Aug 9 2011

This is probably a case of address space fragmentation rather than memory pressure. Bennet, any idea how an XP system will behave when 1GB of virtual space is not available?

Project Member

Comment 9 by, Aug 9 2011

agreed. when there isn't enough contiguous virtual address space available, that is exactly the message that we'd generate.
Labels: -Mstone-15 Mstone-14
Project Member

Comment 11 by, Aug 9 2011

I think that this is likely being caused by dlls loading at their (scattered) preferred addresses in a way that's not leaving a 1GB gap in the address space.  This could be because of externally injected dlls when someone has a lot of random crap installed on their system (many windows programs inject dlls into every other process).

Chatting with cpu about this, he suggested two ideas to deal with this:
- Turn the soft failure into a crash dump, then we could find out what's been loaded into the process and get an idea about its address space layout
- When we create the process, we can use VirtualAllocEx to pre-allocate 1GB of RAM from the parent process.  This should be possible before any code runs.

However, Mark Seaborn recently started seeing this on his virtual machine and believes this to be a recent regression as the original reporter describes.  If that's the case, then perhaps it's not third party dlls to blame.  It could be something odd like chrome.dll getting large enough that it's affecting the available contiguous address space.  Since Mark appears to have a repro case, he's going to try to get a crash dump of the process and we'll get a bit more info.

In the meantime, if somebody else would like to take a swing at Carlos' VirtualAllocEx idea, we could get a build to Mark to see if it fixes his repro case.
Project Member

Comment 12 by, Aug 10 2011

Project Member

Comment 13 by, Aug 10 2011

Attached is a memory mapping listing from 32-bit Windows XP which shows a gap of only 1006MB above chrome.dll on my test setup, which causes NaCl startup to fail.  chrome.dll is 162MB -- I suspect it has become larger than usual because of MSVC's incremental linking.  (The NaCl tests started failing on my XP VM after rebuilding Chromium but *without* any code change.)

I generated the listing as follows:
 * Remove the code from that deletes any resulting crash dump files.
 * Run "run_inbrowser_trusted_crash_in_startup_test" on Chromium with disable_dynamic_plugin_loading=1.
 * Run the binary dump through Breakpad's "minidump_dump" tool to get human-readable output.
 * Pipe that text through the script attached.

Note that the memory mapping listing is incomplete because it only shows code objects, not heap/stack memory etc.

2.6 KB View Download
920 bytes View Download
29.5 KB Download
Project Member

Comment 14 by, Aug 12 2011

Today I was able to run the ToT Chromium.exe on a hive instance of a Windows XP 32 bit machine. Trying to load any .nexe causes the NaCl startup to fail.

I was able to get the VirtualAllocEx call to succeed in reserving 1Gb of memory, but the load still fails. As Erik pointed out, that's because I didn't disable the old call to VirtualAlloc. It looks like that is in src/native_client/src/trusted/service_runtime/win/sel_memory.c

where the memory is reserved, released and then re-reserved in 64 Kb chunks. If I understand the code correctly, we'll have to somehow pass the address from our new call down to the sel_ldr code and skip the VirtualAlloc call (but still call VirtualFree) on Windows XP 32 bit. I'm open to suggestions on how to do this without too many changes to the codebase. Is there a way to pass it on the command line?
Project Member

Comment 15 by, Aug 12 2011

Project Member

Comment 16 by, Aug 12 2011

I don't think these should be merged.  Let's talk today.
Project Member

Comment 17 by, Aug 12 2011

Status: Assigned
Updating owner to bbudge to reflect reality.
Project Member

Comment 18 by, Aug 12 2011

Added a patch for Chrome and NaCl which fixes this issue. We should decide if we want to use the 'VirtualQuery' approach to find the pre-reserved memory or to use a global to pass the address to the process.

Comment 19 by, Aug 13 2011

How long will it take until the fixes are in Chrome's Ubuntu package repository?
Status: Fixed
Closing, as the fix is in for Windows. For Linux, a separate set of bugs track this: (disable Linux temporarily) (fix the issue)
Project Member

Comment 21 by, Aug 26 2011

If anyone gets a chance, please verify that it's fixed on any Windows 7 or XP 32-bit systems at hand.
It seems to work on my netbook now in canary. Unfortunately, it required an OS reinstall in the meanwhile so it is not the exact same system that had the problem in the first place, but it is still 32bit XP.
Project Member

Comment 23 by, Aug 26 2011

It worked for me yesterday morning with Chrome Canary, Windows XP 32-bit,
1GB physical memory.

I'm getting the same error message: "NativeClient: NaCl module load failed: Insufficient memory to load file"

I'm trying on this address:

Ubuntu 10.04 LTS
chrome: 15.0.865.0 dev
chromium: 15.0.865.0 (Developer Build 98568 Linux) Ubuntu 10.04

Is this fixed only on Windows or should the fix work on linux browsers too?
Project Member

Comment 25 by, Sep 1 2011

Linux fix is pending, should roll in the next week or so. See Native Client
 issue 480  and Chromium issue 92964.

I also get this when trying the hello world demo here: 
or any of my own compiled modules.

I've got the following setup:
Windows XP 32 bit SP3 4 GB RAM (only 3.5 show up in task manager due to 32 bit limitation)

Chrome 17.0.963.12


Sign in to add a comment