Closed Bug 1574972 Opened 2 years ago Closed 2 years ago

Crash in [@ OOM | large | NS_ABORT_OOM | nsTSubstring<T>::Assign | nsJSUtils::GetCallingLocation]


(Core :: DOM: Core & HTML, defect)

68 Branch
Not set



Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- fixed
firefox68 --- wontfix
firefox69 --- fixed
firefox70 --- fixed


(Reporter: marcia, Assigned: mccr8)



(Keywords: crash, regression, Whiteboard: [MemShrink])

Crash Data


(1 file)

This bug is for crash report bp-6a56b512-77d2-4eb4-8d84-2cb090190819.

Seen while looking at 68.0.2 release crash stats, #16th overall currently: Present in 67 release but seems more prominent in 68, where we had almost 2K crashes.

Strong correlation to de locale:

100.0% in signature vs 07.63% overall) moz_crash_reason = MOZ_CRASH(OOM)
(99.06% in signature vs 15.57% overall) useragent_locale = de
(100.0% in signature vs 51.78% overall) address = 0x0
(97.17% in signature vs 52.14% overall) Module "startupCache.4.little" = true
(100.0% in signature vs 56.05% overall) Module "linker" = true
(97.71% in signature vs 54.15% overall) cpu_arch = arm
(73.45% in signature vs 31.37% overall) Module "app_process32" = true
(97.71% in signature vs 58.53% overall) android_cpu_abi2 = armeabi
(97.71% in signature vs 58.53% overall) android_cpu_abi = armeabi-v7a
(95.42% in signature vs 62.29% overall) Module "" = true
(95.42% in signature vs 62.30% overall) Module "" = true


  • i was just reading in a private tab. suddenly, firefox closed
Top 10 frames of crashing thread:

0 NS_ABORT_OOM xpcom/base/nsDebugImpl.cpp:604
1 nsTSubstring<char>::Assign xpcom/string/nsTSubstring.cpp:381
2 nsJSUtils::GetCallingLocation dom/base/nsJSUtils.cpp:49
3 nsJSScriptTimeoutHandler::nsJSScriptTimeoutHandler dom/base/nsJSTimeoutHandler.cpp:183
4 NS_CreateJSTimeoutHandler dom/base/nsJSTimeoutHandler.cpp:273
5 nsGlobalWindowInner::SetTimeoutOrInterval dom/base/nsGlobalWindowInner.cpp:5576
6 nsGlobalWindowInner::SetTimeout dom/base/nsGlobalWindowInner.cpp:5535
7 mozilla::dom::Window_Binding::setTimeout dom/bindings/WindowBinding.cpp:18299
8 bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::MaybeGlobalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3165
9  @0x8f745446 

Component: JavaScript Engine → DOM: Core & HTML

These are all Android crashes. The OOM allocation sizes range from 315016 to 966060 bytes.

The URLs come from a variety of sites, but they all look German, which seems peculiar.

This string assignment can be made fallible. Most call sites ignore the failure, but presumably having an empty file name is okay.

My only theory for this regression is that some German ad network rolled out changes that resulted in extremely large file names, for whatever reason.

Assignee: nobody → continuation
Whiteboard: [MemShrink]

Some German web sites seem to have started to have file names with
hundreds of thousands of bytes long, which is causing OOM crashes on

Pushed by
Make nsJSUtils::GetCallingLocation() fallible. r=smaug
See Also: → 1575335
See Also: → 1575343
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

Please nominate this for Beta and ESR68 approval when you get a chance.

Flags: needinfo?(continuation)

Comment on attachment 9086710 [details]
Bug 1574972 - Make nsJSUtils::GetCallingLocation() fallible.

Beta/Release Uplift Approval Request

  • User impact if declined: Out of memory crashes crashes on German websites for users on Android.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This just throws out some script information in case we run out of memory. It is possible that we'll just end up crashing in a different way.
  • String changes made/needed: none

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: These are mostly Android crashes, and I think Android Firefox is based on ESR so it makes more sense to upload it there.
  • User impact if declined:
  • Fix Landed on Version:
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky):
  • String or UUID changes made by this patch:
Flags: needinfo?(continuation)
Attachment #9086710 - Flags: approval-mozilla-esr68?
Attachment #9086710 - Flags: approval-mozilla-beta?

Comment on attachment 9086710 [details]
Bug 1574972 - Make nsJSUtils::GetCallingLocation() fallible.

Approved for 69.0b16 and Fennec 68.1esr.

Attachment #9086710 - Flags: approval-mozilla-esr68?
Attachment #9086710 - Flags: approval-mozilla-esr68+
Attachment #9086710 - Flags: approval-mozilla-beta?
Attachment #9086710 - Flags: approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.