1438151 - Assertion failure: info.fun->allowSuperProperty() || info.fun->isSelfHostedBuiltin() || info.fun->isAsync(), at js/src/jit/CodeGenerator.cpp:2701

Status: RESOLVED FIXED

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

Description

[Christian Holler (:decoder)]

The attached testcase was found on mozilla-central revision f1a4b64f19b0 (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --cpu-count=2 --disable-oom-functions --disable-oom-functions --spectre-mitigations=off --ion-eager --ion-extra-checks --baseline-eager --ion-check-range-analysis --ion-aa=flow-sensitive --test-wasm-await-tier2), but the testcase itself does not reproduce (permanent Q10 bug).


Backtrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000006a27b1 in js::jit::CodeGenerator::visitLambda (this=0x7fda6bad3000, lir=<optimized out>) at js/src/jit/CodeGenerator.cpp:2700
#1  0x00000000006cb512 in js::jit::CodeGenerator::generateBody (this=this@entry=0x7fda6bad3000) at js/src/jit/CodeGenerator.cpp:5554
#2  0x00000000006cc035 in js::jit::CodeGenerator::generate (this=this@entry=0x7fda6bad3000) at js/src/jit/CodeGenerator.cpp:9741
#3  0x00000000006f6756 in js::jit::GenerateCode (mir=mir@entry=0x7fda6bc8a1c0, lir=0x7fda6bc8c098) at js/src/jit/Ion.cpp:1966
#4  0x000000000074fd39 in js::jit::CompileBackEnd (mir=mir@entry=0x7fda6bc8a1c0) at js/src/jit/Ion.cpp:1988
#5  0x0000000000bb77a8 in js::HelperThread::handleIonWorkload (this=this@entry=0x7fda6c528098, locked=...) at js/src/vm/HelperThreads.cpp:1838
#6  0x0000000000bb7bf2 in js::HelperThread::threadLoop (this=this@entry=0x7fda6c528098) at js/src/vm/HelperThreads.cpp:2227
#7  0x0000000000bb7ea0 in js::HelperThread::ThreadMain (arg=0x7fda6c528098) at js/src/vm/HelperThreads.cpp:1747
#8  0x0000000000bb8432 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul> (this=0x7fda6c519070) at js/src/threading/Thread.h:242
#9  js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start (aPack=0x7fda6c519070) at js/src/threading/Thread.h:235
#10 0x00007fda6e1ba6fa in start_thread (arg=0x7fda6c2fe700) at pthread_create.c:333
#11 0x00007fda6d231b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
rax	0x0	0
rbx	0x7fda6bc91068	140576087937128
rcx	0x7fda6d221a2d	140576110549549
rdx	0x0	0
rsi	0x7fda6d4f0770	140576113493872
rdi	0x7fda6d4ef540	140576113489216
rbp	0x7fda6c2fcca0	140576094669984
rsp	0x7fda6c2fcc20	140576094669856
r8	0x7fda6d4f0770	140576113493872
r9	0x7fda6c2fe700	140576094676736
r10	0x0	0
r11	0x0	0
r12	0x7fda6bad3000	140576086110208
r13	0x0	0
r14	0x7fda6bc8ab88	140576087911304
r15	0x7fda6c2fcc50	140576094669904
rip	0x6a27b1 <js::jit::CodeGenerator::visitLambda(js::jit::LLambda*)+337>
=> 0x6a27b1 <js::jit::CodeGenerator::visitLambda(js::jit::LLambda*)+337>:	movl   $0x0,0x0
   0x6a27bc <js::jit::CodeGenerator::visitLambda(js::jit::LLambda*)+348>:	ud2


:jandem mentioned that even without the testcase, he might have an idea what is causing this. Marking s-s until investigated.

Comment 1

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 2

[Christian Holler (:decoder)]

NI as discussed on IRC.

Comment 3

[Jan de Mooij [:jandem]]

Attachment: Patch

This is "impossible" to reproduce, but I think it's a race that involves:

* JIT compilation thread calls fun->isAsync() as part of the MOZ_ASSERT in CodeGenerator::visitLambda. This uses the script/lazyScript.

* At the same time, the main thread delazifies the function and isAsync gets confused.

This patch moves the assert to the LambdaFunctionInfo constructor and makes LambdaFunctionInfo::fun private. I added LambdaFunctionInfo::funUnsafe() with a comment.

Comment 4

[Tooru Fujisawa [:arai]]

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

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

Thanks :D

::: js/src/jit/MIR.h
@@ +8791,5 @@
>      // the script, and are immutable except for delazification. Record this
>      // information while still on the active thread to avoid races.
> +  private:
> +    CompilerFunction fun_;
> +  public:

put an empty line before this, maybe?

Comment 5

[Jim Mathies [:jimm]]

(In reply to Jan de Mooij [:jandem] from comment #3)
> Created attachment 8952401 [details] [diff] [review]
> Patch
> 
> This is "impossible" to reproduce, but I think it's a race that involves:
> 
> * JIT compilation thread calls fun->isAsync() as part of the MOZ_ASSERT in
> CodeGenerator::visitLambda. This uses the script/lazyScript.
> 
> * At the same time, the main thread delazifies the function and isAsync gets
> confused.
> 
> This patch moves the assert to the LambdaFunctionInfo constructor and makes
> LambdaFunctionInfo::fun private. I added LambdaFunctionInfo::funUnsafe()
> with a comment.

Checking in - can we land this and close?

Comment 6

[Jan de Mooij [:jandem]]

Yeah I wanted to land this today but the tree has been closed for most of the day. Hopefully tomorrow.

Note that this only affects debug builds AFAIK.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4780be3c03b4
Fix race in CodeGenerator::visitLambda in debug builds. r=arai

Comment 8

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/4780be3c03b4