1345458 - Crash [@ js::CompartmentChecker::fail] with evalInCooperativeThread and setInterruptCallback

Status: RESOLVED DUPLICATE of bug 1347539

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 58753259bfeb (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-stdcxx-compat --disable-profiling --disable-debug --enable-optimize, run with --fuzzing-safe --thread-count=2 --ion-eager --baseline-eager):

See attachment.


Backtrace:

 received signal SIGSEGV, Segmentation fault.
js::CompartmentChecker::fail (c1=<optimized out>, c2=<optimized out>) at js/src/jscntxtinlines.h:40
#0  js::CompartmentChecker::fail (c1=<optimized out>, c2=<optimized out>) at js/src/jscntxtinlines.h:40
#1  0x00000000006fbe5f in js::CompartmentChecker::check (c=<optimized out>, this=<optimized out>) at js/src/jscntxtinlines.h:61
#2  js::CompartmentChecker::check (type=..., this=<optimized out>) at js/src/jscntxtinlines.h:183
#3  js::assertSameCompartment<JSScript*, js::TypeSet::Type> (t2=<synthetic pointer>, t1=<synthetic pointer>, cx=0x7ffff6926800) at js/src/jscntxtinlines.h:227
#4  js::TypeScript::SetThis (cx=cx@entry=0x7ffff6926800, script=script@entry=0x7ffff52c41f0, type=...) at js/src/vm/TypeInference-inl.h:617
#5  0x00000000006f32e2 in js::TypeScript::SetThis (value=..., script=<optimized out>, cx=0x7ffff6926800) at js/src/vm/TypeInference-inl.h:635
#6  js::jit::DoTypeMonitorFallback (cx=0x7ffff6926800, payload=<optimized out>, stub=0x7ffff69dc020, value=..., res=...) at js/src/jit/SharedIC.cpp:2401
#7  0x0000052b9f9b6745 in ?? ()
[...]
#10 0x0000000000000000 in ?? ()
rax	0x1ae7420	28210208
rbx	0x7ffff52c41f0	140737306706416
rcx	0x7fffffc5	2147483589
rdx	0x7ffff6ef7780	140737336276864
rsi	0xdd7215	14512661
rdi	0x7fffffffc370	140737488339824
rbp	0x2	2
rsp	0x7fffffffc8b0	140737488341168
r8	0x0	0
r9	0x3b	59
r10	0x0	0
r11	0xfffffffffffffff5	-11
r12	0x7ffff6926800	140737330178048
r13	0x7ffff52c41f0	140737306706416
r14	0x7ffff6926800	140737330178048
r15	0x7ffff69dc020	140737330921504
rip	0x55d08e <js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)+46>
=> 0x55d08e <js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)+46>:	movl   $0x0,0x0
   0x55d099 <js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)+57>:	ud2    


The attached testcase is slightly intermittent and gets more intermittent when I try to reduce it.

Comment 1

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 2

[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/24931c1b6d9e
parent:      343765:66739e3ff974
parent:      343847:1ce3e5778328
user:        Carsten "Tomcat" Book
date:        Mon Feb 20 14:05:25 2017 +0100
summary:     merge mozilla-inbound to mozilla-central a=merge

Not all ancestors of this changeset have been checked.
Use bisect --extend to continue the bisection from
the common ancestor, c3cbadc5d2fa.

This iteration took 220.116 seconds to run.

Oops! We didn't test rev 1ce3e5778328, a parent of the blamed revision! Let's do that now.
Rev 1ce3e5778328: Updating to rev 1ce3e5778328 in the /srv/repos/JSBugMon/repos/mozilla-central repository...
Compiling...
Testing... [Uninteresting] It didn't crash. (0.052 seconds)
good (not interesting) 
As expected, the parent's label is the opposite of the blamed rev's label.

The bug was introduced by a merge (it was not present on either parent).
I don't know which patches from each side of the merge contributed to the bug. Sorry.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

autoBisect probably got confused there. Setting needinfo? from :bhackett as a start since this involves evalInCooperativeThread.

Comment 4

[Fuzzing Team]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 35398cae65c1).

Comment 5

[Brian Hackett [Laid off!]]

I was able to reproduce this and determine the compartment mismatch is because of the same AttachFinishedCompilations issue as bug 1347539.  The thread finishing the compilations clobbers a zone group's owner context and then jitcode running on the other thread goes and fetches the wrong JSContext from the owner context field, leading to various insanity.