If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Getting `uncaught exception: out of memory` that disables site features and requires hard refresh

RESOLVED FIXED in Firefox 55

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
4 months ago
3 months ago

People

(Reporter: Harald, Assigned: nbp)

Tracking

(Blocks: 1 bug)

unspecified
mozilla55
x86_64
Mac OS X
Points:
---

Firefox Tracking Flags

(firefox55 fixed)

Details

(Whiteboard: [MemShrink])

Attachments

(2 attachments)

(Reporter)

Description

4 months ago
For some days I am n several web sites I get `uncaught exception: out of memory` in the console. If it happens during page load, only hard refresh gets the page unstuck. If it happens after page load, buttons stop working.

I disabled some extensions that I am working on that use the geckoProfiler API, but that didn't help. Still have to test in safe mode.

about:support: https://pastebin.mozilla.org/9023584
(Reporter)

Comment 1

4 months ago
Restarted with safe mode:

uncaught exception: out of memory  (unknown)
uncaught exception: out of memory (unknown)
uncaught exception: out of memory  (unknown)
uncaught exception: out of memory  (unknown)
uncaught exception: out of memory  (unknown)

After that functions fail.

TypeError: window._init is not a function  mgadget:5:21
TypeError: parentDocShell.getDocShellEnumerator is not a function[Learn More]  tab.js:62:23

Maybe this is JS and parsing related?
uncaught exception: out of memory seems to come from ReportOutOfMemory which is a SpiderMonkey thing AFAICT.
Component: DOM → JavaScript Engine
Flags: needinfo?(shu)
Can you save and attach an about:memory report when in that state? Though maybe you can't run it.
Also you could check what your memory usage is in whatever system monitor you have on your OS.
Whiteboard: [MemShrink]

Comment 5

4 months ago
A bunch of different things can throw OOM in JS, including but not limited to parsing.

Is there any more STR? Is a particular site triggering this?

Updated

4 months ago
Flags: needinfo?(shu)
(Reporter)

Comment 6

4 months ago
System memory didn't show anything weird, Firefox wasn't taking over RAM.

I see this across several sites. Gmail stands out as I have it in a pinned tab. I also have this on https://health.graphics/quantum and while opening this bugzilla entry (memory error then failed calls for $, YAHOO and init_module_visibility; causing the "Edit Bug" to not work)
(Reporter)

Comment 7

4 months ago
Created attachment 8874586 [details]
memory-report.json.gz
Nothing too weird in that memory report.

I do see
3,077.32 MB ── gfx-textures-peak
2,486.68 MB ── resident-peak
in there, so maybe if the memory usage is spiking in multiple processes at once it would cause issues? The JS peak is very small, though.
(Reporter)

Comment 9

4 months ago
I remembered that played around with dom.script_loader.bytecode_cache.eager and dom.script_loader.bytecode_cache.enabled but didn't flip them back. Now I did and I will report back after some testing.
(In reply to :Harald Kirschner :digitarald from comment #9)
> I remembered that played around with dom.script_loader.bytecode_cache.eager
> and dom.script_loader.bytecode_cache.enabled but didn't flip them back. Now
> I did and I will report back after some testing.

CC'ing nbp. There might be a bogus ReportOutOfMemory call somewhere.
(Assignee)

Comment 11

4 months ago
I managed to reproduce this issue while visiting https://health.graphics/quantum with a debug build and got, after reloading the page:

[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x22f9360): Maybe request bytecode
[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x22f9360): Stream complete (url = https://health.graphics/app.623afb.js)
[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x22f9360): Bytecode length = 3305343
Assertion failure: mRawPtr != nullptr (You can't dereference a NULL nsCOMPtr with operator->().), at …/dist/include/nsCOMPtr.h:763

The following pref should be used to reproduce the issue:
  "dom.script_loader.bytecode_cache.enabled" = true
  "dom.script_loader.bytecode_cache.strategy" = -1

I will investigate, as this indeed seems related to the bytecode decoding.
Assignee: nobody → nicolas.b.pierron
Blocks: 900784
Status: NEW → ASSIGNED
(Assignee)

Comment 12

4 months ago
(In reply to Nicolas B. Pierron [:nbp] from comment #11)
> Assertion failure: mRawPtr != nullptr (You can't dereference a NULL nsCOMPtr
> with operator->().), at …/dist/include/nsCOMPtr.h:763

This was due to some code from my dirty work-directory.
The actual error also sounds related to the bytecode decoding:

[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x2204980): Maybe request bytecode
[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x22290b0): Maybe request bytecode
[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x22290b0): Stream complete (url = https://bugzilla.mozilla.org/data/assets/5c28254b41747e1ee1f88345ffac5c99.js?1496165815)
[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x22290b0): Bytecode length = 202828
[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x2204980): Stream complete (url = https://bugzilla.mozilla.org/data/assets/f0d8f806b435d5c1c42cd109e6626548.js?1496165815)
[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x2204980): Bytecode length = 2377762
[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x2204980): Decode Bytecode & Join and Execute
JavaScript error: , line 0: uncaught exception: out of memory
[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x226cd70): Cannot cache anything (cacheInfo = (nil))
[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x226cd70): Compile And Exec
[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x226cd70): Bytecode-cache: disabled (rv = 530002, script = 0x7f23370291c0)
JavaScript error: https://bugzilla.mozilla.org/show_bug.cgi?id=1370345, line 38: ReferenceError: YAHOO is not defined
[Main Thread]: D/ScriptLoader ScriptLoadRequest (0x22290b0): Decode Bytecode and Execute
Assertion failure: tr != JS::TranscodeResult_Failure_BadBuildId && tr != JS::TranscodeResult_Failure_WrongCompileOption, at …/dom/base/nsJSUtils.cpp:309
(Assignee)

Comment 13

4 months ago
(In reply to Nicolas B. Pierron [:nbp] from comment #12)
> Assertion failure: tr != JS::TranscodeResult_Failure_BadBuildId && tr !=
> JS::TranscodeResult_Failure_WrongCompileOption, at
> …/dom/base/nsJSUtils.cpp:309

This assertion is caused by the fact that MOZ_BUILDID is not given on the command line of every file, thus what should never happen because we are supposed to have a build ID serialized into the mime type of the alternate data type cause an assertion to be raised because of a different Build ID:

  decodedBuildId = "20170530153730"
  buildId = "20170606115301"
  kBytecodeMimeType = "javascript/moz-bytecode-MOZ_BUILDID"
           instead of "javascript/moz-bytecode-20170606115301"

(In reply to Nicolas B. Pierron [:nbp] from comment #12)
> [Main Thread]: D/ScriptLoader ScriptLoadRequest (0x2204980): Decode Bytecode
> & Join and Execute
> JavaScript error: , line 0: uncaught exception: out of memory

This OOM is the same issue as above, except that the off main thread parser convert this issue into an OOM, as it did not produced any script.

> [Main Thread]: D/ScriptLoader ScriptLoadRequest (0x226cd70): Compile And Exec
> JavaScript error: https://bugzilla.mozilla.org/show_bug.cgi?id=1370345, line
> 38: ReferenceError: YAHOO is not defined

This issue is likely an inline script which expected the previous script to be loaded successfully.
(Assignee)

Comment 14

4 months ago
Created attachment 8875280 [details] [diff] [review]
Create JS bytecode mime type based on the platform BuildID instead of MOZ_BUILDID macro.

This patch removes the NS_STRINGIFY(MOZ_BUILDID) macro because the macro is
not defined on the command line, except for the nsAppRunner.cpp.

Including buildid.h causes dom/script/ScriptLoader.cpp to be rebuilt every
time, and to relink firefox.  Thus, I took the approach of generating the
mime type based on the mozilla::PlatformBuildID which expose the content of
the constant stored in nsAppRunner.cpp.

This should be enough to handle nightly rebuilds, as we currently use the
same information through xpcom to provided it to the XDR encoding and
decoding functions.
(Assignee)

Updated

4 months ago
Attachment #8875280 - Flags: review?(mrbkap)
Comment on attachment 8875280 [details] [diff] [review]
Create JS bytecode mime type based on the platform BuildID instead of MOZ_BUILDID macro.

Review of attachment 8875280 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/base/nsContentUtils.cpp
@@ +728,5 @@
>  
>    Preferences::AddIntVarCache(&sBytecodeCacheStrategy,
>                                "dom.script_loader.bytecode_cache.strategy", 0);
>  
> +  nsCString buildID(mozilla::PlatformBuildID());

Might as well make this an nsDependentCString.

::: dom/script/ScriptLoadHandler.cpp
@@ +283,4 @@
>        mRequest->mDataType = ScriptLoadRequest::DataType::Bytecode;
>        TRACE_FOR_TEST(mRequest->mElement, "scriptloader_load_bytecode");
>      } else {
> +      MOZ_ASSERT(altDataType.EqualsLiteral(""));

IsEmpty()
Attachment #8875280 - Flags: review?(mrbkap) → review+

Comment 16

3 months ago
Pushed by npierron@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/911cfe859296
Create JS bytecode mime type based on the platform BuildID instead of MOZ_BUILDID macro. r=mrbkap

Comment 17

3 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/911cfe859296
Status: ASSIGNED → RESOLVED
Last Resolved: 3 months ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in before you can comment on or make changes to this bug.