1402649 - Crash [@ js::IsObjectValueInCompartment] or Assertion failure: uintptr_t(&obj) > 0x1000 || uintptr_t(&obj) == 0x48, at dist/include/js/Value.h:364 with OOM

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 8db0c4ecd94c (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-stdcxx-compat --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --baseline-eager --ion-offthread-compile=off):

loadFile(`
function parseAndEvaluate(source) {
    let m = parseModule(source);
    m.declarationInstantiation();
}
parseAndEvaluate("async function a() { await 2 + 3; }")
`);
function loadFile(lfVarx) {
    oomTest(function() {
        eval(lfVarx);
    });
}



Backtrace:

 received signal SIGSEGV, Segmentation fault.
0x00000000004c51fc in js::IsObjectValueInCompartment (comp=<optimized out>, v=...) at js/src/jsobj.h:1377
#0  0x00000000004c51fc in js::IsObjectValueInCompartment (comp=<optimized out>, v=...) at js/src/jsobj.h:1377
#1  js::NativeObject::checkStoredValue (v=..., this=0x7ffff469e5c0) at js/src/vm/NativeObject.h:968
#2  js::NativeObject::setSlot (this=0x7ffff469e5c0, slot=2, value=...) at js/src/vm/NativeObject.h:974
#3  0x0000000000c08565 in js::NativeObject::setSlotWithType (this=0x7ffff469e5c0, cx=0x7ffff6948000, shape=0x7ffff46b3920, value=..., overwriting=<optimized out>) at js/src/vm/NativeObject-inl.h:427
#4  0x0000000000bea5a0 in NativeSetExistingDataProperty (result=..., v=..., shape=..., obj=..., cx=0x7ffff6948000, receiver=...) at js/src/vm/NativeObject.cpp:2501
#5  SetExistingProperty (cx=0x7ffff6948000, obj=..., obj@entry=..., id=..., id@entry=..., v=..., receiver=receiver@entry=..., pobj=..., pobj@entry=..., prop=..., result=...) at js/src/vm/NativeObject.cpp:2727
#6  0x0000000000c090bf in js::NativeSetProperty<(js::QualifiedBool)1> (cx=cx@entry=0x7ffff6948000, obj=obj@entry=..., id=id@entry=..., value=..., receiver=..., receiver@entry=..., result=...) at js/src/vm/NativeObject.cpp:2791
#7  0x0000000000b2e282 in js::ModuleEnvironmentObject::setProperty (cx=0x7ffff6948000, obj=..., id=..., v=..., receiver=..., result=...) at js/src/vm/EnvironmentObject.cpp:580
#8  0x0000000000a4afd6 in JSObject::nonNativeSetProperty (cx=0x7ffff6948000, obj=..., obj@entry=..., id=id@entry=..., v=..., v@entry=..., receiver=receiver@entry=..., result=...) at js/src/jsobj.cpp:1031
#9  0x00000000005a9cb0 in js::SetProperty (result=..., receiver=..., v=..., id=..., obj=..., cx=<optimized out>) at js/src/vm/NativeObject.h:1606
#10 js::SetProperty (v=..., name=<optimized out>, obj=..., cx=0x7ffff6948000) at js/src/jsobj.h:904
#11 js::ModuleObject::instantiateFunctionDeclarations (cx=cx@entry=0x7ffff6948000, self=self@entry=...) at js/src/builtin/ModuleObject.cpp:1065
#12 0x0000000000c40baf in intrinsic_InstantiateModuleFunctionDeclarations (cx=0x7ffff6948000, argc=<optimized out>, vp=<optimized out>) at js/src/vm/SelfHosting.cpp:2100
#13 0x000003fdda62d473 in ?? ()
#14 0x00007ffff46b29c0 in ?? ()
#15 0x00007fffffff7c28 in ?? ()
#16 0x00007fffffff7c80 in ?? ()
#17 0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x7ffff469e5c0	140737293968832
rcx	0x4	4
rdx	0x0	0
rsi	0x2	2
rdi	0x7fffffff7820	140737488320544
rbp	0x7fffffff7640	140737488320064
rsp	0x7fffffff7620	140737488320032
r8	0x1	1
r9	0x7fffffff7840	140737488320576
r10	0x1	1
r11	0x7ffff6995108	140737330630920
r12	0x2	2
r13	0x7fffffff7820	140737488320544
r14	0x7ffff692b000	140737330196480
r15	0x1	1
rip	0x4c51fc <js::NativeObject::setSlot(unsigned int, JS::Value const&)+284>
=> 0x4c51fc <js::NativeObject::setSlot(unsigned int, JS::Value const&)+284>:	mov    (%rax),%rax
   0x4c51ff <js::NativeObject::setSlot(unsigned int, JS::Value const&)+287>:	cmp    0x10(%rax),%r14

Comment 1

[Fuzzing Team]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/81c056ef9e19
user:        André Bargull
date:        Fri Jul 28 12:55:07 2017 -0700
summary:     Bug 1382306 - Create async function wrapper when instantiating module functions. r=jonco

This iteration took 280.532 seconds to run.

Comment 2

[Jon Coppeard (:jonco)]

Attachment: bug1402649-async-wrapper

One problem is lack of error handling when creating wrappers for async functions/generators (bug 1382306).  I should have spotted that in review.

The other issue is the GC cell pointer asserts in bug 1399944 are too weak and allow Value::setObject() to take be passed a (dereferenced) null pointer.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f9df54bc3999
Fix valid GC cell pointer asserts and error handling in module instantiation r=sfink

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f9df54bc3999

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Please request Beta approval on this when you get a chance.

Comment 6

[Jon Coppeard (:jonco)]

Comment on attachment 8911786 [details] [diff] [review]
bug1402649-async-wrapper

Approval Request Comment
[Feature/Bug causing the regression]: Bug 1382306 and bug 1399944.
[User impact if declined]: Possible crashes when using modules (which are preffed off by default).  Lower than intended assertion coverage when created object values.
[Is this code covered by automated tests?]: Yes.
[Has the fix been verified in Nightly?]: Yes.
[Needs manual test from QE? If yes, steps to reproduce]: No.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: No.
[Why is the change risky/not risky?]: This is mainly debug mode only changes to improve assertions around null object values, and one release mode null pointer check.
[String changes made/needed]: None

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8911786 [details] [diff] [review]
bug1402649-async-wrapper

I don't see a single crash since last month. Let it ride the train.