The nacl_helper (even if it's not activated) consumes 84.1 GB virtual memory
Reported by sauer.be...@gmail.com, Oct 18 2015
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36 Steps to reproduce the problem: 1. Install Ubuntu 15.04 64Bit 2. Install Chrome 45.0.2454.85 (64-bit) 3. Run Chrome What is the expected behavior? Chrome should NOT slow down my whole system... The exact problem was described here: https://productforums.google.com/forum/#!topic/chrome/H4D29Js2Snc What went wrong? Whenever I run Chrome, its nacl_helper will consume up to 84.1G of virtual memory, which in turn seems to put some stress on my ssd and makes the whole system unstable and slows it down. Did this work before? Yes Some versions ago Chrome version: 45.0.2454.85 Channel: n/a OS Version: Ubuntu 15.04 64bit Flash Version: Shockwave Flash 18.0 r0 As mentioned, there was an discussion on the google productforums, but I could not find an appropriate ticket. Maybe it was fixed already and this is a regession bug.
Oct 20 2015,
Unable to repro this issue on Ubuntu Trusty (14.04) for Google Chrome Stable Version - 46.0.2490.71 @Sauer.benjamin: Could you please perform the steps mentioned beneath and let us know your observations, which would help us in triaging it further. 1. Update your Google Chrome to Latest Stable Version - 46.0.2490.71 2. Re-test the same on a clean profile [chrome://settings -> Add Person] Thank you.
Nov 23 2015,
Due to lack of user response we are closing this issue for now. Please feel free to file a new issue if you come across this issue again.
Apr 6 2016,
Please revisit this issue. I got the same situation on Archlinux. I'm using a browser profile that was created long ago in previous versions of Chrome. History and cache were not cleaned up. From my understanding (please check the screenshot), the nacl_helper is spawned by a chrome-sandbox process of some sort. That happens as soon as I start Chromium. The virtual memory is allocated almost immediately afterwards. As suggested, I created a clean profile, switched to that profile, then closed all instances of Chromium. I started Chromium with my clean profile as default browsing profile. I could then no longer see the nacl_helper processes. The allocated VM issue was gone. As soon as I switched back to my normal profile, the 84G VM were allocated again. Chromium: 49.0.2623.110 (64-bit) OS: Linux 4.4.5-1-ARCH x86_64 GNU/Linux
May 17 2016,
I noticed almost precisely the same issue and traced it to the Google Play Music extension. Disabling the extension killed the the 84.1g nacl_helper process, and enabling it again spawned a new nacl_helper process with the same virtual memory demand. Chrome:50.0.2661.102 (64-bit) OS: Ubuntu 16.04 LTS
May 17 2016,
That's a pretty nice find. Thanks! I completely removed the Google Play Music extension and the 84G nacl_helper process was gone. I reinstalled the extension afterwards but I haven't so far been able to reproduce the issue. The nacl_helper process seems to be there but the VM doesn't exceed 40mb or so. I'll keep monitoring it. Chromium: 50.0.2661.102 (64-bit)
May 18 2016,
Great find !!! I had exactly the same issue. Just disabling the Google Play Music extension gets rid of the nacl_helper and it's 84,1 Gb of virtual Memory. Thanks a lot ! Let's hope we hear from google soon about a solution on that! Chrome: Version 50.0.2661.102 (64-bit) Linux Mint 17.3 Rosa (Linux 3.19.0-32-generic x86_64)
Aug 27 2016,
I have the same issue, with the exact same value: 84.1GB. But I don't have the Google Play Music extension, and I tried disabling every single extension I have, with no luck. Happening in Chrome 51.0.2704.106 (64-bit) under Ubuntu 16.04.
Sep 20 2016,
Sep 28 2016,
@MTV: Team, could someone please have a look into this issue. Thank you.
Sep 28 2016,
This issue is related to Google Play Music.
Sep 28 2016,
#11 Is it? #7 says he doesn't have Google Play Music, and disabled all extensions.
Sep 29 2016,
Detected this problem today. Uninstalling google play music solved it for me.
Oct 11 2016,
The issue may be “related” to Google Play Music, but I'm pretty confident it's not confined to users of a Google Play Music extension. I've never installed such an extension (and wasn't even aware it existed). I've never used Google Play Music or even activated an account in that service.
Oct 20 2016,
Oct 25 2016,
I am seeing the same issue *without* Google Play Music but with the VideoStream extension installed. Videostream is for streaming movies to the Google Chromecast. configuration: Ubuntu 14.04 / Chrome 53.0.2785.143 (64-bit) I only see these nacl_helper readings (240 - 300% CPU activity, 84GB VM) if I am streaming non-mp4 movies. Apparently, videostream is transcoding them on the fly. If it happens, everything is slowing down so much that these movies are basically unwatchable.
Nov 4 2016,
I have the same issue. Fedora 24. Google Chrome 54.0.2840.90 (64-bit). I don't have Google Play Music extension, but I use BlueJeans. It might be related.
Nov 10 2016,
I'm also experiencing this issue, although today was the first time I'd seen it (I've made no significant changes to my computer lately, and only ever install security updates). There were two users on Reddit (https://www.reddit.com/r/chrome/comments/498br6/help_why_is_nacl_helper_84g_large_also_overnight/) who saw this issue with _exactly_ 84 gigabytes of ram. Maybe that exact amount is a clue? Ubuntu 14.04 uname is Linux 3.13.0-38-generic #65somerville1-Ubuntu SMP Wed Oct 15 02:15:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Google Chrome Version 53.0.2785.143 (64-bit) I've never installed google play music on this computer. Extensions I use: Adblock Plus 1.12.4 Authy 1.5.0 Authy Chrome Extension 1.0.2 Google Docs 0.9 Google Docs Offline 1.4 Google Sheets 1.1 Google Slides 0.9 Lastpass 4.1.31 OneLogin for Google Chrome 3.1.2 Postman 4.8.1 Virtu Email Encryption 3.21.3
Dec 13 2016,
I've been seeing this behaviour for a while; doesn't seem to cause any particular problems. Occasionally, though, two such processes spawn, which did seem to be associated with some performance issues (though it's hard to disentangle that from Chrome bloat itself, which is definitely a recurrent theme). Now, however, it's routinely spawning *four*, almost identically sized. Even with all extensions disabled (and all but one uninstalled). ChromeOS 55.
Dec 28 2016,
I see this on Ubuntu 14.04 plus Chrome. Linux 3.13.0-106-generic It is usually exactly 84.0 Gigabytes of memory, and is associated with a Chrome slowdown. I do not use Google Play Music. Extensions: Gif Stopper Google Docs Offline Lastpass Screenleap (screen share) The Great Suspender
Dec 28 2016,
"Memory map" from "System Monitor", showing two 40GiB blocks:
Jan 2 2017,
I am having the same issue on Ubuntu 16 LTS. Don't know if this have some impact, but when System monitor shows dependencies, there is two nacl_helper processes, one under the other. Both combined exceed 100 Gig of virtual memory. i will soon try to do the same on another systems, and post here if something else appears. Also, maybe related to this is the fact that opening Chrome is enough to, under some circunstances, make both VMWARE Workstation and my zfs on linux go crazy... Closing Chrome make things get back to normal all times. unfortunately I haven't anymore a license to Vmwre to see if this still happens... I use XEN on this computer and apparently it is all ok.
Jan 4 2017,
For the second part of my comment above, turning off hardware acceleration apparently solved the issue with zfs, so the problem was not related to the one on this thread.
Jan 12 2017,
Disabling the Google Play Music extension through the Extensions UI immediately removes the 84 GB and returns it down to 26.4 MiB Virtual Memory. Extensions: AdBlock 3.8.4 The most popular Chrome extension, with over 40 million users! Blocks ads all over the web. Awesome Screenshot: Screen capture, Annotate 3.8.5 Dreditor 1.2.17 GitHub EditorConfig 1.1.0 Gmail Offline Sync Optimiser 6.5 Google Docs 0.9 Google Docs Offline 1.4 Google Play Music 1.349.0 Google Sheets 1.1 Inbox by Gmail 184.108.40.2069 JetBrains IDE Support 2.0.9 REST Console 4.0.2 Videostream for Google Chromecast™ 2.16.1222.0 VS Launcher 1.0
Jan 18 2017,
Confirming #24's comment about disabling Google Play Music extension. virtual mem size is 84+GB with GPM enabled; back to 27MB with it disabled.
Jan 28 2017,
I was having the same problem. I dont have Google Play music extension. I've disabled every extension, but no success. The problem was a tab open using Telegram. I closed the Telegram web tab, and the 84+4 DB disappears. I've attached my htop output when the Telegram Web app was opened.
Jan 28 2017,
OK, I'm impressed: never managed more than four instances at once. But then again, never used Telegram, either. Is there some API commonality between all these different apparently correlated applications?
Mar 1 2017,
I don't have the Google Play Music extension, but comparing PIDs in htop and the chrome task manager it appears that the Google Keep chrome app also causes nacl_helper to consume ~84GB of virtual memory.
Mar 16 2017,
Same here: 84G with Google Play Music extension, 37M without it. Version 57.0.2987.98 (64-bit) on NAME="Ubuntu" VERSION="16.04.2 LTS (Xenial Xerus)"
Mar 23 2017,
Thanks a lot for the Google Play Music solution, it really helped!
Mar 27 2017,
I'm not running the Google Play Music extension, but I see the 84G map with the Videostream extension on 57.0.2987.98 The first time I disabled the Videostream extension the nacl_helper went away, but it did not go away the second time I enabled/disabled the extension. /proc/<pid>/maps shows a bunch of big address range anonymous maps, so it isn't just mmaping a large file.
Jul 1 2017,
OK, variation on the previously reported theme: now using a different model, a CB3-431, and have a nacl_helper that runs (in the tradition 84G of VM) whenever I have a crouton instance running in xiwi mode. What's more, if the nacl_helper is killed, it hangs crouton. OK, so fair enough, let it run! However... periodically it still forks *another* nacl_helper! Which seems to impact performance, as before. And it's not clear which one to kill, either!
Aug 18 2017,
Aug 18 2017,
Folks, virtual address space / VM size is not RAM consumption, nor is it the amount of memory that is swapped to disk. For the RAM consumption you may want to look at the resident size, which is quite reasonable (a few MB) in all the reports that include that number. For swap usage, you may want to look at numbers from 'free'.
Jan 10 2018,
Same issue here on latest and up to date Fedora Desktop. I have 20 Gb ram and no swap. Deleting the Google Music extension solved the problem.
Jan 10 2018,
Folks, virtual address space is not a global resource that is scarce or "consumed". Each process has its own separate 256TB (in 64 bits) of address space, and can use it however it wants without causing "swapping" or "slowdown" or "consuming RAM".
How about the CPU issue. I don't care about the virtual space if it doesn't matter, but the CPU usage is enormous! I get around 400% on my 4 core CPU. I find this happens with Android apps I use through ArcWelder.
For me the CPU issue is... highly intermittent. As is the number of processes. Currently there's just one, with modest CPU usage. Great. Except I've still no idea why it's running at all, which makes me further concerned about when it equally unpredictably spawns *more*, and those further seemingly randomly turn into CPU hogs.
Sign in to add a comment