Closed
Bug 1296667
Opened 9 years ago
Closed 9 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)
Tracking
()
RESOLVED
FIXED
mozilla52
| Tracking | Status | |
|---|---|---|
| firefox51 | --- | fix-optional |
| firefox52 | --- | fixed |
People
(Reporter: decoder, Unassigned)
References
Details
(Keywords: assertion, bugmon, testcase, Whiteboard: [jsbugmon:update])
Attachments
(1 file)
|
7.92 KB,
patch
|
h4writer
:
review+
|
Details | Diff | Splinter Review |
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
Updated•9 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Comment 1•9 years ago
|
||
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
Updated•9 years ago
|
Flags: needinfo?(nicolas.b.pierron)
Comment 2•9 years ago
|
||
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 3•9 years ago
|
||
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+
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
Comment 6•9 years ago
|
||
(In reply to Hannes Verschore [:h4writer] from comment #4)
> ping to land?
Thanks.
Flags: needinfo?(nicolas.b.pierron)
Comment 7•9 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox52:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Comment 8•9 years ago
|
||
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.
Description
•