From 559c556ef8faecb8919a8161e2c030493e91c2ab Mon Sep 17 00:00:00 2001 From: "jyasskin@chromium.org" Date: Thu, 1 May 2014 08:26:38 +0000 Subject: [PATCH] Avoid crashing if we can't allocate a new user-script segment. This isn't a great solution, since it'll make new renderers ignore changes to the extension set after we hit the FD limit. The long-term solution might be to intentionally-crash at a lower level any time we exhaust the allowed file descriptors. BUG=358862 Review URL: https://codereview.chromium.org/266663003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@267481 0039d316-1c4b-4281-b951-d872f2087c98 --- chrome/browser/extensions/user_script_master.cc | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/chrome/browser/extensions/user_script_master.cc b/chrome/browser/extensions/user_script_master.cc index e04d7af7dc75..8a56f45d9156 100644 --- a/chrome/browser/extensions/user_script_master.cc +++ b/chrome/browser/extensions/user_script_master.cc @@ -341,6 +341,19 @@ void UserScriptMaster::NewScriptsAvailable(base::SharedMemory* handle) { } else { // We're no longer loading. script_reloader_ = NULL; + + if (handle == NULL) { + // This can happen if we run out of file descriptors. In that case, we + // have a choice between silently omitting all user scripts for new tabs, + // by nulling out shared_memory_, or only silently omitting new ones by + // leaving the existing object in place. The second seems less bad, even + // though it removes the possibility that freeing the shared memory block + // would open up enough FDs for long enough for a retry to succeed. + + // Pretend the extension change didn't happen. + return; + } + // We've got scripts ready to go. shared_memory_.swap(handle_deleter); -- 2.11.4.GIT