Closed Bug 1235677 Opened 5 years ago Closed 5 years ago

Assertion failure: OOM_maxAllocations == (4294967295U), at ../../../dist/include/js/Utility.h:202


(Core :: JavaScript Engine, defect)

Not set



Tracking Status
firefox45 --- wontfix
firefox46 --- wontfix
firefox47 --- wontfix
firefox48 --- fixed


(Reporter: gkw, Assigned: jonco)



(4 keywords, Whiteboard: [jsbugmon:ignore])


(5 files, 1 obsolete file)

In both jsfunfuzz and Langfuzz results, we are seeing the following assertion:

Assertion failure: OOM_maxAllocations == (4294967295U), at ../../../dist/include/js/Utility.h

across multiple platforms and architectures. Testcases are really difficult to reproduce.


Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x080eefe9 in js::AutoEnterOOMUnsafeRegion::~AutoEnterOOMUnsafeRegion (
    this=0xf6972610, __in_chrg=<optimized out>)
    at ../../../dist/include/js/Utility.h:202
To enable execution of this file add
	add-auto-load-safe-path /home/ubuntu/mozilla-central/js/src/debugarmsim/dist/bin/
line to your configuration file "/home/ubuntu/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/ubuntu/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
#0  0x080eefe9 in js::AutoEnterOOMUnsafeRegion::~AutoEnterOOMUnsafeRegion (this=0xf6972610, __in_chrg=<optimized out>) at ../../../dist/include/js/Utility.h:202
#1  0x083f2f0d in js::jit::AllocationIntegrityState::InstructionInfo::InstructionInfo (this=0xf02e7b9c, o=...) at js/src/jit/RegisterAllocator.h:74
#2  0x083e31a8 in new_<js::jit::AllocationIntegrityState::InstructionInfo const&> (aU=..., aDst=0xf02e7b9c) at ../../dist/include/mozilla/Vector.h:74
#3  copyConstructN<js::jit::AllocationIntegrityState::InstructionInfo> (aU=..., aN=12, aDst=0xf02e7b9c) at ../../dist/include/mozilla/Vector.h:130
#4  internalAppendN (aNeeded=12, aT=..., this=0xf6972914) at ../../dist/include/mozilla/Vector.h:1112
#5  appendN (aNeeded=12, aT=..., this=0xf6972914) at ../../dist/include/mozilla/Vector.h:1102
#6  js::jit::AllocationIntegrityState::record (this=this@entry=0xf6972910) at js/src/jit/RegisterAllocator.cpp:19
#7  0x08303afc in js::jit::GenerateLIR (mir=mir@entry=0xeff01158) at js/src/jit/Ion.cpp:1916
#8  0x0830765f in js::jit::CompileBackEnd (mir=mir@entry=0xeff01158) at js/src/jit/Ion.cpp:1992
#9  0x0867eee3 in js::HelperThread::handleIonWorkload (this=this@entry=0xf713fb24) at js/src/vm/HelperThreads.cpp:1263
#10 0x08680b58 in js::HelperThread::threadLoop (this=0xf713fb24) at js/src/vm/HelperThreads.cpp:1581
#11 0x086cb071 in nspr::Thread::ThreadRoutine (arg=0xf7102180) at js/src/vm/PosixNSPR.cpp:45
#12 0xf771ff59 in start_thread (arg=0xf6973b40) at pthread_create.c:312
#13 0xf74ebc4e in clone () from /lib32/
eax	0x0	0
ebx	0x97cb7b8	159168440
ecx	0xf75aa88c	-145053556
edx	0x0	0
esi	0x97cbbf8	159169528
edi	0xf69726b0	-157866320
ebp	0xf69725c8	4137100744
esp	0xf69725b0	4137100720
eip	0x80eefe9 <js::AutoEnterOOMUnsafeRegion::~AutoEnterOOMUnsafeRegion()+137>
=> 0x80eefe9 <js::AutoEnterOOMUnsafeRegion::~AutoEnterOOMUnsafeRegion()+137>:	movl   $0xca,0x0
   0x80eeff3 <js::AutoEnterOOMUnsafeRegion::~AutoEnterOOMUnsafeRegion()+147>:	call   0x80f90b0 <abort()>

Filing this first in the hopes that the stacks are enough to aid diagnosis.
Attached file Testcase (obsolete) —
Attachment #8702761 - Attachment is obsolete: true
Jon, you were able to help with bug 1207569 which was a similar assert, are you able to help here?
Flags: needinfo?(jcoppeard)
These were happening as recently as 28 Dec 2015 (m-c rev 7c83da46ea74), whereas bug 1209911 seems to have landed in Oct 2015.
m-c rev for stack 1 in comment 0: 66fb852962c0
m-c rev for stack 2 in comment 2: 35b211eaad1f
m-c rev for stack 3 in comment 3: 0babaa3edcf9
It seems we have two helper threads doing an Ion compilation while the main thread is inside oomTest().  That shouldn't be possible because we restrict the number of Ion compilation threads in this case.
I haven't been able to see anything wrong by looking at the code.

Gary, do you have any kind of testcase for this?
Flags: needinfo?(jcoppeard) → needinfo?(gary)
No, unfortunately not at the moment.
Flags: needinfo?(gary)
Naveed, can you help find an assignee?
Flags: needinfo?(nihsanullah)
It's possible that failing to synchronise with helper threads in restOOMFailure could cause this.
Attachment #8730720 - Flags: review?(terrence)
Comment on attachment 8730720 [details] [diff] [review]

Review of attachment 8730720 [details] [diff] [review]:

Seems like a reasonable hypothesis and probably something we should take regardless.
Attachment #8730720 - Flags: review?(terrence) → review+
Keywords: leave-open
Gary please let me know if this made any difference.
Flags: needinfo?(gary)
Your patch landing resulted in assertion failures similar to this one:

Assertion failure: oom::maxAllocations == (18446744073709551615ULL), at dist/include/js/Utility.h:222

The original one of Assertion failure: OOM_maxAllocations == (4294967295U), at dist/include/js/Utility.h:202 no longer seems to happen.
Flags: needinfo?(gary) → needinfo?(jcoppeard)
jonco is working on this. clearing NI
Flags: needinfo?(nihsanullah)
Assignee: nobody → jcoppeard
This is another debug patch that adds an assertion on entry to AutoEnterOOMUnsafeRegion to catch racy use from multiple threads.  Hopefully this will show something up.
Flags: needinfo?(jcoppeard)
Attachment #8735900 - Flags: review?(terrence)
Attachment #8735900 - Flags: review?(terrence) → review+
Gary: regression from when?
Flags: needinfo?(gary)
Unable to tell for sure. No reliable testcase.
Flags: needinfo?(gary)
No longer depends on: 1262203
See Also: → 1263218
Wondering if this is fixed or if the diagnostic work helps nail down a cause.
Flags: needinfo?(jcoppeard)
Gary, can you let me know if this still happens after the patch in bug 1263218 lands?
Flags: needinfo?(jcoppeard) → needinfo?(gary)
I've not seen anything yet.
Flags: needinfo?(gary)
moving this forward a release for triage.
This is a dupe, and the problem is testing only. WONTFIX 47.
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1263218
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
You need to log in before you can comment on or make changes to this bug.