1462353 - Assertion failure: data.maxArgv[0].isObject() || data.maxArgv[0].isMagic(JS_UNINITIALIZED_LEXICAL), at mozilla-central/js/src/jit/BaselineJIT.cpp:135

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect, P3)

Description

[Alex Gaynor [:Alex_Gaynor]]

This bug was found by Google's OSS-Fuzz running their custom internal JS fuzzer. I am refiling it in our issue tracker.

Please note that they apply a 90-day disclose timeline to all bugs:

/mnt/scratch0/clusterfuzz/slave-bot/builds/clusterfuzz-builds-no-engine_spidermonkey_6aad6e0d14f81d36f48dbd887aa56b38e87859f7/revisions/js --cpu-count=2 --disable-oom-functions --fuzzing-safe /mnt/scratch0/clusterfuzz/slave-bot/inputs/fuzzer-testcases/fuzz-58.js
	
	[Environment] ASAN_OPTIONS = redzone=512:strict_memcmp=0:allow_user_segv_handler=1:allocator_may_return_null=1:handle_sigfpe=1:handle_sigbus=1:detect_stack_use_after_return=0:alloc_dealloc_mismatch=0:print_scariness=1:max_uar_stack_size_log=16:detect_odr_violation=0:handle_sigill=1:coverage=0:use_sigaltstack=1:fast_unwind_on_fatal=1:detect_leaks=0:print_summary=1:handle_abort=1:check_malloc_usable_size=0:detect_container_overflow=1:symbolize=0:handle_segv=1
	
	Assertion failure: data.maxArgv[0].isObject() || data.maxArgv[0].isMagic(JS_UNINITIALIZED_LEXICAL), at mozilla-central/js/src/jit/BaselineJIT.cpp:135
	AddressSanitizer:DEADLYSIGNAL
	=================================================================
	==17885==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000d5b606 bp 0x7ffc18d3ef10 sp 0x7ffc18d3e900 T0)
	==17885==The signal is caused by a WRITE memory access.
	==17885==Hint: address points to the zero page.
	SCARINESS: 10 (null-deref)
	#0 0xd5b605 in EnterBaseline(JSContext*, js::jit::EnterJitData&) mozilla-central/js/src/jit/BaselineJIT.cpp:129:5
	#1 0xd5b605 in js::jit::EnterBaselineAtBranch(JSContext*, js::InterpreterFrame*, unsigned char*) mozilla-central/js/src/jit/BaselineJIT.cpp:226
	#2 0x9d86c8 in Interpret(JSContext*, js::RunState&) mozilla-central/js/src/vm/Interpreter.cpp:2037:28
	#3 0x9afd30 in js::RunScript(JSContext*, js::RunState&) mozilla-central/js/src/vm/Interpreter.cpp:417:12
	#4 0x9e8bf0 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) mozilla-central/js/src/vm/Interpreter.cpp:489:15
	#5 0x9ea987 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) mozilla-central/js/src/vm/Interpreter.cpp:535:10
	#6 0x2246ffc in js::CallSelfHostedFunction(JSContext*, JS::Handle<js::PropertyName*>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) mozilla-central/js/src/vm/SelfHosting.cpp:1852:12
	#7 0x1c6464b in AsyncFunctionResume(JSContext*, JS::Handle<js::PromiseObject*>, JS::Handle<JS::Value>, ResumeKind, JS::Handle<JS::Value>) mozilla-central/js/src/vm/AsyncFunction.cpp:190:10
	#8 0x1c62def in AsyncFunctionStart(JSContext*, JS::Handle<js::PromiseObject*>, JS::Handle<JS::Value>) mozilla-central/js/src/vm/AsyncFunction.cpp:203:12
	#9 0x1c62def in WrappedAsyncFunction(JSContext*, unsigned int, JS::Value*) mozilla-central/js/src/vm/AsyncFunction.cpp:89
	#10 0xa12d1b in js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) mozilla-central/js/src/vm/JSContext-inl.h:280:15
	#11 0x9e8c4c in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) mozilla-central/js/src/vm/Interpreter.cpp:467:16
	#12 0x9d0048 in js::CallFromStack(JSContext*, JS::CallArgs const&) mozilla-central/js/src/vm/Interpreter.cpp:522:12
	#13 0x9d0048 in Interpret(JSContext*, js::RunState&) mozilla-central/js/src/vm/Interpreter.cpp:3086
	#14 0x9afd30 in js::RunScript(JSContext*, js::RunState&) mozilla-central/js/src/vm/Interpreter.cpp:417:12
	#15 0x9ee243 in js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::AbstractFramePtr, JS::Value*) mozilla-central/js/src/vm/Interpreter.cpp:700:15
	#16 0x9ef0eb in js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) mozilla-central/js/src/vm/Interpreter.cpp:732:12
	#17 0x1aa2a11 in ExecuteScript(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSScript*>, JS::Value*) mozilla-central/js/src/jsapi.cpp:4721:12
	#18 0x1aa2e4f in JS_ExecuteScript(JSContext*, JS::Handle<JSScript*>) mozilla-central/js/src/jsapi.cpp:4754:12
	#19 0x5f140a in RunFile(JSContext*, char const*, _IO_FILE*, bool) mozilla-central/js/src/shell/js.cpp:836:14
	#20 0x5f140a in Process(JSContext*, char const*, bool, FileKind) mozilla-central/js/src/shell/js.cpp:1305
	#21 0x581982 in ProcessArgs(JSContext*, js::cli::OptionParser*) mozilla-central/js/src/shell/js.cpp:8412:14
	#22 0x581982 in Shell(JSContext*, js::cli::OptionParser*, char**) mozilla-central/js/src/shell/js.cpp:8808
	#23 0x581982 in main mozilla-central/js/src/shell/js.cpp:9281
	#24 0x7f19279e682f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291

Comment 1

[Alex Gaynor [:Alex_Gaynor]]

Attachment: clusterfuzz-testcase-minimized-5113352396210176.js

Ooops, forgot to include the reproducer.

Comment 2

[Alex Gaynor [:Alex_Gaynor]]

Originally filed on OSS-Fuzz on May 9 (sorry about the filing delay, was at a conference), so the 90 day deadline starts then.

Comment 3

[Daniel Veditz [:dveditz]]

Guessing at the severity. Jan, please correct.

Comment 4

[Jan de Mooij [:jandem]]

We have an async arrow function inside a derived class constructor... When we resume the generator frame, we think we are "constructing" (because we have a new.target object), but that's wrong - arrows inherit the new.target from the outer constructor and that doesn't make the arrow frame itself "constructing".

I don't think this is actually s-s. We're guaranteed to have an |undefined| this-value; it's just that we mark the frame as constructing and push an unnecessary (never used because arrow function) new.target Value.

The nice thing is that it made me realize generators and async functions are not constructors, so there's some generator code we can remove (for instance the new.target slot of the generator object). Legacy generators were constructible, I think, but they're gone.

Comment 5

[Jan de Mooij [:jandem]]

Attachment: Patch

See comment 4. Most of this is clean up of the generator code. When we create the generator object we now assert the frame is not constructing.

Comment 6

[André Bargull [:anba]]

With the patch, bug 1454345 can probably now be closed as a dup of this bug.

Comment 7

[Tooru Fujisawa [:arai]]

Comment on attachment 8976698 [details] [diff] [review]
Patch

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

Nice cleanup :D

::: js/src/vm/Stack-inl.h
@@ +330,5 @@
>      script->ensureNonLazyCanonicalFunction();
>  
>      LifoAlloc::Mark mark = allocator_.mark();
>  
> +    // Generators and async functions are not constructors.

might be nice to mention async generators as well?

Comment 9

[Jan de Mooij [:jandem]]

(In reply to André Bargull [:anba] from comment #6)
> With the patch, bug 1454345 can probably now be closed as a dup of this bug.

Ah not surprising you got there first :D

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fb1dfccf693f
Remove new.target slot from generators, clean up generator code a bit. r=arai

Comment 11

[Andreea Pavel [:apavel]]

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