1739330 - Assertion failure: mainContextFromAnyThread() == js::TlsContext.get(), at js/src/vm/JSContext.h:1003 or Crash [@ js::TypedObject::initDefault] with WebAssembly Struct Type

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, defect, P2)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 20211103-d4abbebb1327 (debug build, run with --fuzzing-safe --cpu-count=2 --ion-offthread-compile=off --wasm-function-references --wasm-memory64 --wasm-gc):

gczeal(4);
function a(b) {
  binary = wasmTextToBinary(b)
  c = new WebAssembly.Module(binary)
  return new WebAssembly.Instance(c)
}
d = [];
let { newStruct } = a(`
  (type $e (struct))     
    (func (export "newStruct")
      (result eqref)          
      rtt.canon $e      
      struct.new_with_rtt $e
    )
`).exports
d.push(newStruct());
gczeal(14, 7);
throw d;

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  0x0000555557b85872 in js::InlineTypedObject::obj_trace(JSTracer*, JSObject*) ()
#1  0x0000555556f39978 in JSObject::traceChildren(JSTracer*) ()
#2  0x00005555574d650f in UpdateArenaPointers(js::gc::MovingTracer*, js::gc::Arena*) ()
#3  0x00005555574ae12b in UpdateArenaListSegmentPointers(js::gc::GCRuntime*, ArenaListSegment const&) ()
#4  0x00005555574e13fb in js::gc::ParallelWorker<ArenaListSegment, ArenasToUpdate>::run(js::AutoLockHelperThreadState&) ()
#5  0x00005555574f157a in js::GCParallelTask::runTask(js::AutoLockHelperThreadState&) ()
#6  0x00005555574f1847 in js::GCParallelTask::runHelperThreadTask(js::AutoLockHelperThreadState&) ()
#7  0x0000555556e4365b in js::GlobalHelperThreadState::runTaskLocked(js::HelperThreadTask*, js::AutoLockHelperThreadState&) ()
#8  0x0000555556e433f1 in js::GlobalHelperThreadState::runOneTask(js::AutoLockHelperThreadState&) ()
#9  0x0000555556e69d33 in js::HelperThread::threadLoop(js::InternalThreadPool*) ()
#10 0x0000555556e69aec in js::HelperThread::ThreadMain(js::InternalThreadPool*, js::HelperThread*) ()
#11 0x0000555556e9ce78 in js::detail::ThreadTrampoline<void (&)(js::InternalThreadPool*, js::HelperThread*), js::InternalThreadPool*&, js::HelperThread*>::Start(void*) ()
#12 0x00007ffff7bc16ba in start_thread (arg=0x7ffff5fff700) at pthread_create.c:333
rax	0x55555589eed3	93824995684051
rbx	0x7ffff5ffeb78	140737320577912
rcx	0x555558144f20	93825038307104
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7ffff5ffeaa0	140737320577696
rsp	0x7ffff5ffea70	140737320577648
r8	0x7ffff7105770	140737338431344
r9	0x7ffff5fff700	140737320580864
r10	0x0	0
r11	0x0	0
r12	0x7ffff5ffeb70	140737320577904
r13	0x33f028c7e298	57106569355928
r14	0x33f028c7e298	57106569355928
r15	0x7ffff604aa00	140737320888832
rip	0x555557b85872 <js::InlineTypedObject::obj_trace(JSTracer*, JSObject*)+242>
=> 0x555557b85872 <_ZN2js17InlineTypedObject9obj_traceEP8JSTracerP8JSObject+242>:	movl   $0x3eb,0x0
   0x555557b8587d <_ZN2js17InlineTypedObject9obj_traceEP8JSTracerP8JSObject+253>:	callq  0x555556b0801f <abort>

Some of the wasm features specified in the runtime options are still disabled in Nightly, marking s-s anyway because it isn't clear to me which of the features is responsible.

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 3

[Christian Holler (:decoder)]

Similar testcase crashes on 32-bit:

received signal SIGSEGV, Segmentation fault.
__memset_sse2_rep () at ../sysdeps/i386/i686/multiarch/memset-sse2-rep.S:325
#0  __memset_sse2_rep () at ../sysdeps/i386/i686/multiarch/memset-sse2-rep.S:325
#1  0x56966c03 in js::TypedObject::initDefault() ()
#2  0x56966c89 in js::TypedObject::createArray(JSContext*, JS::Handle<js::RttValue*>, unsigned int, js::gc::InitialHeap) ()
#3  0x569e56bc in js::wasm::Instance::arrayNew(js::wasm::Instance*, unsigned int, void*) ()
#4  0x383a1c28 in ?? ()
#5  0x38390074 in ?? ()
#6  0x383900ca in ?? ()
eax	0x0	0
ebx	0x800	2048
ecx	0x3ffcac3d	1073523773
edx	0x0	0
esi	0xf692a0f8	-158162696
edi	0xf69ff000	-157290496
ebp	0xffbbbff8	4290494456
esp	0xffbbbfc4	4290494404
eip	0xf7aabc9a <__memset_sse2_rep+474>
=> 0xf7aabc9a <__memset_sse2_rep+474>:	rep stos %eax,%es:(%edi)
   0xf7aabc9c <__memset_sse2_rep+476>:	je     0xf7aabcb0 <__memset_sse2_rep+496>

Comment 4

[Bugmon [:jkratzer for issues]]

Bugmon Analysis
Unable to reproduce bug 1739330 using build mozilla-central 20211103213618-d4abbebb1327. Without a baseline, bugmon is unable to analyze this bug.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Comment 5

[Lars T Hansen [:lth]]

rhunt, any chance you can take a look to make sure this is not serious?

Comment 6

[Ryan Hunt [:rhunt]]

Attachment: Bug 1739330 - wasm: Don't get JSContext for tracing references in TypedObject. r?lth

This used to be necessary, but is no longer needed.

Comment 7

[Ryan Hunt [:rhunt]]

The first test case and crash looks like just an assertion being triggered by getting a JSContext* on the wrong thread. This used to be necessary when we stored types in JSContext, but we no longer do. This is a bug in wasm-gc and so it's disabled by default. Even when enabled, the assertion looks to be debug only and harmless as we'll grab the JSContext* for the main thread but then do nothing with it.

However, I'm not sure what's going on with second crash linked.

(In reply to Christian Holler (:decoder) from comment #3)

Similar testcase crashes on 32-bit:

received signal SIGSEGV, Segmentation fault.
__memset_sse2_rep () at ../sysdeps/i386/i686/multiarch/memset-sse2-rep.S:325
#0  __memset_sse2_rep () at ../sysdeps/i386/i686/multiarch/memset-sse2-rep.S:325
#1  0x56966c03 in js::TypedObject::initDefault() ()
#2  0x56966c89 in js::TypedObject::createArray(JSContext*, JS::Handle<js::RttValue*>, unsigned int, js::gc::InitialHeap) ()
#3  0x569e56bc in js::wasm::Instance::arrayNew(js::wasm::Instance*, unsigned int, void*) ()
#4  0x383a1c28 in ?? ()
#5  0x38390074 in ?? ()
#6  0x383900ca in ?? ()
eax	0x0	0
ebx	0x800	2048
ecx	0x3ffcac3d	1073523773
edx	0x0	0
esi	0xf692a0f8	-158162696
edi	0xf69ff000	-157290496
ebp	0xffbbbff8	4290494456
esp	0xffbbbfc4	4290494404
eip	0xf7aabc9a <__memset_sse2_rep+474>
=> 0xf7aabc9a <__memset_sse2_rep+474>:	rep stos %eax,%es:(%edi)
   0xf7aabc9c <__memset_sse2_rep+476>:	je     0xf7aabcb0 <__memset_sse2_rep+496>

How did you trigger this? I tried the original test case but wasn't able to trigger it, even with a 32-bit build.

Comment 8

[Julian Seward [:jseward]]

Drive-by comment: rep stos %eax,%es:(%edi) is described as "Fill ECX
bytes/words/dwords [unclear which] at EDI with EAX" (viz, memset). In both
cases EDI ends f000, so I guess it just crossed a page boundary into a
non-writable page, and ECX is huge (0x3ffcac3d 1073523773). And EAX is zero.
So, maybe, memset-zero or bzero with an invalid length?

Comment 9

[Ryan Hunt [:rhunt]]

I am 99% sure that the second crash I was asking about is caused by bug 1742576.

Comment 10

[Ryan Hunt [:rhunt]]

This is not security sensitive as the issue is only in wasm-GC code which is disabled by default. Same with the other failing test case posted here which is bug 1742576.

Comment 11

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

wasm: Don't get JSContext for tracing references in TypedObject. r=lth
https://hg.mozilla.org/integration/autoland/rev/753db1e601c1d686d14c2def5e430a28e2f86909
https://hg.mozilla.org/mozilla-central/rev/753db1e601c1

Comment 12

[BugBot [:suhaib / :marco]]

:rhunt, since this bug contains a bisection range, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.