1206675 - Assertion failure: isObject(), at ../../dist/include/js/Value.h:1237

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Nicolas B. Pierron [:nbp]]

The following testcase crashes on mozilla-central revision a6786bf8d71d (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --thread-count=2 --ion-extra-checks --ion-offthread-compile=off --baseline-eager main.js):

See attachment.


Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000429010 in JS::Value::toObject (this=<optimized out>) at ../../dist/include/js/Value.h:1237
#0  0x0000000000429010 in JS::Value::toObject (this=<optimized out>) at ../../dist/include/js/Value.h:1237
#1  0x00000000004d591b in toObject (this=<optimized out>) at js/src/jsobj.h:547
#2  js::GlobalObject::getOrCreateStarGeneratorFunctionPrototype (cx=<optimized out>, global=...) at js/src/vm/GlobalObject.h:573
#3  0x00000000004f8740 in js::frontend::Parser<js::frontend::FullParseHandler>::functionDef (this=this@entry=0x7fffffffb230, inHandling=inHandling@entry=js::frontend::InAllowed, yieldHandling=yieldHandling@entry=js::frontend::YieldIsName, funName=funName@entry=..., kind=kind@entry=js::frontend::Statement, generatorKind=generatorKind@entry=js::StarGenerator, invoked=invoked@entry=js::frontend::Parser<js::frontend::FullParseHandler>::PredictUninvoked) at js/src/frontend/Parser.cpp:2410
#4  0x00000000004f898d in js::frontend::Parser<js::frontend::FullParseHandler>::functionStmt (this=this@entry=0x7fffffffb230, yieldHandling=yieldHandling@entry=js::frontend::YieldIsName, defaultHandling=defaultHandling@entry=js::frontend::NameRequired) at js/src/frontend/Parser.cpp:2877
#5  0x00000000004f738d in js::frontend::Parser<js::frontend::FullParseHandler>::statement (this=this@entry=0x7fffffffb230, yieldHandling=yieldHandling@entry=js::frontend::YieldIsName, canHaveDirectives=<optimized out>) at js/src/frontend/Parser.cpp:6599
#6  0x00000000004f781a in js::frontend::Parser<js::frontend::FullParseHandler>::statements (this=this@entry=0x7fffffffb230, yieldHandling=yieldHandling@entry=js::frontend::YieldIsName) at js/src/frontend/Parser.cpp:3090
#7  0x00000000004f7bdb in js::frontend::Parser<js::frontend::FullParseHandler>::functionBody (this=this@entry=0x7fffffffb230, inHandling=inHandling@entry=js::frontend::InAllowed, yieldHandling=js::frontend::YieldIsName, kind=kind@entry=js::frontend::Statement, type=type@entry=js::frontend::Parser<js::frontend::FullParseHandler>::StatementListBody) at js/src/frontend/Parser.cpp:1129
#8  0x00000000004ceb5f in js::frontend::Parser<js::frontend::FullParseHandler>::standaloneFunctionBody (this=this@entry=0x7fffffffb230, fun=..., fun@entry=..., formals=formals@entry=..., generatorKind=generatorKind@entry=js::NotGenerator, inheritedDirectives=..., newDirectives=newDirectives@entry=0x7fffffffab50, enclosingStaticScope=enclosingStaticScope@entry=...) at js/src/frontend/Parser.cpp:959
#9  0x000000000063a9f2 in BytecodeCompiler::compileFunctionBody (this=this@entry=0x7fffffffabb0, fun=fun@entry=..., formals=formals@entry=..., generatorKind=generatorKind@entry=js::NotGenerator) at js/src/frontend/BytecodeCompiler.cpp:708
#10 0x000000000063ac7d in CompileFunctionBody (cx=<optimized out>, fun=..., options=..., formals=..., srcBuf=..., enclosingStaticScope=..., generatorKind=js::NotGenerator) at js/src/frontend/BytecodeCompiler.cpp:922
#11 0x000000000063ace4 in js::frontend::CompileFunctionBody (cx=cx@entry=0x7ffff6907000, fun=..., fun@entry=..., options=..., formals=..., formals@entry=..., srcBuf=..., enclosingStaticScope=..., enclosingStaticScope@entry=...) at js/src/frontend/BytecodeCompiler.cpp:932
#12 0x0000000000ba531a in FunctionConstructor (cx=0x7ffff6907000, argc=<optimized out>, vp=<optimized out>, generatorKind=<optimized out>) at js/src/jsfun.cpp:1927
#13 0x00007ffff7ff51d7 in ?? ()
#14 0x00007fffffffd080 in ?? ()
#15 0x00007fffffffc3a0 in ?? ()
#16 0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x7ffff7e5e060	140737352425568
rcx	0x7ffff6ca53cd	140737333842893
rdx	0x0	0
rsi	0x7ffff6f7a9d0	140737336814032
rdi	0x7ffff6f791c0	140737336807872
rbp	0x7fffffffa320	140737488331552
rsp	0x7fffffffa320	140737488331552
r8	0x7ffff7fd4780	140737353959296
r9	0x1	1
r10	0x7fffffffa0e0	140737488330976
r11	0x7ffff6c27960	140737333328224
r12	0x3	3
r13	0x7fffffffb230	140737488335408
r14	0x0	0
r15	0x7fffffffb260	140737488335456
rip	0x429010 <JS::Value::toObject() const+28>
=> 0x429010 <JS::Value::toObject() const+28>:	movl   $0x4d5,0x0
   0x42901b <JS::Value::toObject() const+39>:	callq  0x49c3d0 <abort()>

Comment 1

[Nicolas B. Pierron [:nbp]]

Attachment: Testcase

Comment 2

[Nicolas B. Pierron [:nbp]]

Looking at the stack trace, this issue seems to be related with the crash seen in Bug 1206485.

Comment 3

[Fuzzing Team]

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

Comment 4

[Terrence Cole [:terrence]]

I am not able to reproduce. My compiler is |gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)|.

Comment 5

[Jeff Walden [:Waldo]]

Looks like a bootstrapping issue in generator/iterator bootstrapping code, likely because of bad OOM handling:

1450	js::InitIteratorClasses(JSContext* cx, HandleObject obj)
1451	{
1452	    Rooted<GlobalObject*> global(cx, &obj->as<GlobalObject>());
1453	    if (!GlobalObject::initIteratorClasses(cx, global))
1454	        return nullptr;
1455	    if (!GlobalObject::initGeneratorClasses(cx, global))
1456	        return nullptr;
1457	    return global->getIteratorPrototype();

If 1453 succeeds, it sets the JSProto_Iterator constructor that guards in getOrCreateStarGenerator.  But 1455 could subsequently fail and leave the slot still unset.  That would trigger this assertion pretty handily.

This may be/probably is a duplicate of a bug 1111506.  Maybe I should just fix this now, rather than prioritizing other stuff.  :-\

Incidentally, this test is finicky.  Running it as

[jwalden@find-waldo-now unzipped]$ gdb --args ~/moz/slots/js/src/dbg/js/src/js --ion-offthread-compile=off --baseline-eager -f main.js

where `pwd` contains the unzipped files triggers the failure for me.  Running it from the enclosing directory

[jwalden@find-waldo-now tmp]$ gdb --args ~/moz/slots/js/src/dbg/js/src/js --ion-offthread-compile=off --baseline-eager -f unzipped/main.js

does not trigger the failure.  Something spooky about allocations and path/argument lengths, but not too important with the issue diagnosed.

Comment 6

[Terrence Cole [:terrence]]

Ah, I was running it from outside the test directory, so that's probably why I didn't hit it!

Comment 7

[Andrew McCreight [:mccr8]]

Can we mark this fixed now, Jeff? Comment 5 says this is a dupe of bug 1111506, which is marked as a dupe of bug 1101561, which is now marked fixed.

Comment 8

[Jeff Walden [:Waldo]]

Yeah, we can so mark.

Comment 9

[Daniel Veditz [:dveditz]]

I assume we're not going to backport bug 1101561 to ESR? If we're not we should mark that status field "wontfix".

Comment 10

[Al Billings [:abillings - ex-MoCo]]

Are we going to won't fix this for the upcoming ESR? Dan's question is from December 1 and this is fixed in 44.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Indeed, this is too big to be backported to esr...
Thanks