Closed Bug 1296667 Opened 5 years ago Closed 5 years ago

Assertion failure: fallibleScope_ ([OOM] Cannot allocate a new chunk in an infallible scope.), at js/src/ds/LifoAlloc.cpp:105

Categories

(Core :: JavaScript Engine, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla52
Tracking Status
firefox51 --- fix-optional
firefox52 --- fixed

People

(Reporter: decoder, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, bugmon, testcase, Whiteboard: [jsbugmon:update])

Attachments

(1 file)

The following testcase crashes on mozilla-central revision cf06fbc83175 (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug --without-intl-api --enable-optimize --target=i686-pc-linux-gnu, run with --fuzzing-safe --ion-offthread-compile=off):

args = ""
for (i = 0; i < 2000; i++) {
    args += "arg" + i;
    if (i != 1999) args += ",";
}
MyFunc = MyObject = Function(args, "for (var i = 0; i < MyFunc.length; i++ )   break; eval('this.arg'+i +'=arg'+i) ");
new function TestCase() TestCase(eval("var EXP_1 = new MyObject; var EXP_2 = new MyObject; EXP_1 - EXP_2"));



Backtrace:

 received signal SIGSEGV, Segmentation fault.
0x088b1f58 in js::LifoAlloc::getOrCreateChunk (this=0xffffa2a0, n=64) at js/src/ds/LifoAlloc.cpp:105
#0  0x088b1f58 in js::LifoAlloc::getOrCreateChunk (this=0xffffa2a0, n=64) at js/src/ds/LifoAlloc.cpp:105
#1  0x081a23c4 in js::LifoAlloc::allocImpl (n=64, this=0xffffa2a0) at js/src/ds/LifoAlloc.h:225
#2  js::LifoAlloc::allocInfallible (this=0xffffa2a0, n=64) at js/src/ds/LifoAlloc.h:291
#3  0x0835a6ae in js::jit::TempAllocator::allocateInfallible (bytes=64, this=0xffffa270) at js/src/jit/JitAllocPolicy.h:46
#4  js::jit::TempObject::operator new (alloc=..., nbytes=64) at js/src/jit/JitAllocPolicy.h:247
#5  js::jit::MInstruction::operator new (alloc=..., nbytes=64) at js/src/jit/MIR.h:1046
#6  js::jit::MParameter::New (alloc=..., index=520, types=0xf1462100) at js/src/jit/MIR.cpp:1867
#7  0x082811ed in js::jit::IonBuilder::initParameters (this=0xffffa3ac) at js/src/jit/IonBuilder.cpp:1188
#8  0x082b6fe6 in js::jit::IonBuilder::build (this=0xffffa3ac) at js/src/jit/IonBuilder.cpp:830
#9  0x082c3762 in js::jit::AnalyzeNewScriptDefiniteProperties (cx=0xf7953000, fun=0xf156c980, group=0xf15554c0, baseobj=..., initializerList=0xffffa980) at js/src/jit/IonAnalysis.cpp:4055
#10 0x087d8f43 in js::TypeNewScript::maybeAnalyze (this=0xf797f560, cx=0xf7953000, group=0xf15554c0, regenerate=0xffffaa70, force=false) at js/src/vm/TypeInference.cpp:3750
#11 0x085ad16e in js::CreateThisForFunctionWithProto (cx=0xf7953000, callee=..., newTarget=..., proto=..., newKind=js::GenericObject) at js/src/jsobj.cpp:960
#12 0x085ad83c in js::CreateThisForFunction (cx=0xf7953000, callee=..., newTarget=..., newKind=js::GenericObject) at js/src/jsobj.cpp:1015
#13 0x086d09d9 in js::RunState::maybeCreateThisForConstructor (this=0xffffae60, cx=0xf7953000) at js/src/vm/Interpreter.cpp:327
#14 0x0820f4ff in js::jit::CanEnterBaselineMethod (cx=0xf7953000, state=...) at js/src/jit/BaselineJIT.cpp:383
#15 0x086eb196 in Interpret (cx=0xf7953000, state=...) at js/src/vm/Interpreter.cpp:2922
[...]
#34 0xf7be2c4a in ?? ()
eax	0x0	0
ebx	0x8000	32768
ecx	0xf7da4864	-136689564
edx	0x0	0
esi	0xf1478fd0	-246968368
edi	0xffffa2a0	-23904
ebp	0xffffa078	4294942840
esp	0xffffa010	4294942736
eip	0x88b1f58 <js::LifoAlloc::getOrCreateChunk(unsigned int)+728>
=> 0x88b1f58 <js::LifoAlloc::getOrCreateChunk(unsigned int)+728>:	movl   $0x0,0x0
   0x88b1f62 <js::LifoAlloc::getOrCreateChunk(unsigned int)+738>:	ud2
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20160705060723" and the hash "359a15f3afea99a3422bc03d5b699c6f93aa9a94".
The "bad" changeset has the timestamp "20160705063922" and the hash "977e5fd31b3d8f83e3c6b4560f6784fbabdbf49a".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=359a15f3afea99a3422bc03d5b699c6f93aa9a94&tochange=977e5fd31b3d8f83e3c6b4560f6784fbabdbf49a
Flags: needinfo?(nicolas.b.pierron)
Blocks: 1264948
Flags: needinfo?(nicolas.b.pierron)
The test case highlighted both initParameters and rewriteParameters issues.
I modified the test case to ensure that it finishes while reporting the
original errors.

This patch allocate MParameters in a fallible manner in initParameters, and
update MParameter class accordingly.  This also adds an ensureBallast call
next to rewriteParameters loop.
Attachment #8788463 - Flags: review?(hv1989)
Comment on attachment 8788463 [details] [diff] [review]
Ensure enough ballast space when given large list of parameters.

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

::: js/src/jit/MIR.cpp
@@ +1864,5 @@
> +// Define |THIS_SLOT| as part of this translation unit, as it is used to
> +// specialized the parameterized |New| function calls introduced by
> +// TRIVIAL_NEW_WRAPPERS.
> +//
> +// see http://stackoverflow.com/questions/5391973/undefined-reference-to-static-const-int

Can you remove this link? Not the place to put this in the source code. You can mention it in the bugzilla comments.
Attachment #8788463 - Flags: review?(hv1989) → review+
ping to land?
Flags: needinfo?(nicolas.b.pierron)
Pushed by npierron@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fc69176b3f83
Ensure enough ballast space when given large list of parameters. r=h4writer
(In reply to Hannes Verschore [:h4writer] from comment #4)
> ping to land?

Thanks.
Flags: needinfo?(nicolas.b.pierron)
https://hg.mozilla.org/mozilla-central/rev/fc69176b3f83
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Mark 51 as fix-optional. If it's worth uplifting to 51, feel free to nominate it.
You need to log in before you can comment on or make changes to this bug.