Bug 278041 – [ Mac Debug WK2 ] workers/worker-to-worker.html is consistently crashing

• Component: WebAssembly
• Status: RESOLVED CONFIGURATION CHANGED

[Robert Jenner]

workers/worker-to-worker.html

is consistently crashing on WK2 macOS Ventura Debug and later.

HISTORY:
https://results.webkit.org/?suite=layout-tests&test=workers%2Fworker-to-worker.html


CRASH URL:
https://build.webkit.org/results/Apple-Sonoma-Debug-AppleSilicon-WK2-Tests/282173@main%20(3717)/workers/worker-to-worker-crash-log.txt


CRASH STDERR:
1   0x12cae4af8 JSC::Wasm::OpcodeOrigin::OpcodeOrigin(JSC::Wasm::OpType, unsigned int, unsigned long)
2   0x12cac8afc JSC::Wasm::OpcodeOrigin::OpcodeOrigin(JSC::Wasm::OpType, unsigned int, unsigned long)
3   0x12caa2270 JSC::Wasm::OMGIRGenerator::origin()
4   0x12caa8158 JSC::Wasm::OMGIRGenerator::addTableFill(unsigned int, JSC::B3::Variable*, JSC::B3::Variable*, JSC::B3::Variable*)
5   0x12cb43adc JSC::Wasm::FunctionParser<JSC::Wasm::OMGIRGenerator>::parseExpression()
6   0x12cb34ed8 JSC::Wasm::FunctionParser<JSC::Wasm::OMGIRGenerator>::parseBody()
7   0x12cac4cec JSC::Wasm::FunctionParser<JSC::Wasm::OMGIRGenerator>::parse()
8   0x12cac8e84 JSC::Wasm::parseAndCompileOMG(JSC::Wasm::CompilationContext&, JSC::Wasm::OptimizingJITCallee&, JSC::Wasm::FunctionData const&, JSC::Wasm::TypeDefinition const&, WTF::Vector<JSC::Wasm::UnlinkedWasmToWasmCall, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, JSC::Wasm::CalleeGroup&, JSC::Wasm::ModuleInformation const&, JSC::MemoryMode, JSC::Wasm::CompilationMode, unsigned int, std::__1::optional<bool>, unsigned int, JSC::Wasm::TierUpCount*)
9   0x12cb8c7dc JSC::Wasm::OMGPlan::work(JSC::Wasm::Plan::CompilationEffort)
10  0x12cc2a3f0 JSC::Wasm::Worklist::Thread::work()
11  0x12a5bb45c WTF::AutomaticThread::start(WTF::AbstractLocker const&)::$_0::operator()() const
12  0x12a5bb00c WTF::Detail::CallableWrapper<WTF::AutomaticThread::start(WTF::AbstractLocker const&)::$_0, void>::call()
13  0x12a5d7814 WTF::Function<void ()>::operator()() const
14  0x12a70d718 WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)
15  0x12a719f98 WTF::wtfThreadEntryPoint(void*)
16  0x19c48af94 _pthread_start
17  0x19c485d34 thread_start
com.apple.WebKit.WebContent.Development terminated (pid 16806) for reason: crash
LEAK: 1 WebPageProxy

[Radar WebKit Bug Importer]

<rdar://problem/133784222>

[EWS]

Test gardening commit 282190@main (20bce1134f43): <https://commits.webkit.org/282190@main>

Reviewed commits have been landed. Closing PR #32129 and removing active labels.

[Alexey Proskuryakov]

This test doesn't use WASM, so the issue must be caused by a preceding test that we should skip.

[Mark Lam]

According to https://results.webkit.org/?suite=layout-tests&test=workers%2Fworker-to-worker.html, the crashes have stopped manifesting.

[Alexey Proskuryakov]

Robert suspects that this was fixed by 282247@main. Still need to revert the gardening commit, of course.

[Mark Lam]

(In reply to Alexey Proskuryakov from comment #5)
> Robert suspects that this was fixed by 282247@main. Still need to revert the
> gardening commit, of course.

282247@main is Wasm specific.  Since this test does not exercise Wasm at all, it cannot possibly be caused by 282247@main.  The original crash trace may be erroneous and from a different test failing due to the bug that 282247@main fixed.

[EWS]

Test gardening commit 282295@main (d7a3f89ea3cd): <https://commits.webkit.org/282295@main>

Reviewed commits have been landed. Closing PR #32248 and removing active labels.

[Alexey Proskuryakov]

As discussed in Slack, the stack trace is correct, and it is not uncommon that some async processing leaks from one test to another. It's usually a problem in itself that navigating away doesn't entirely stop all background WebKit code for it.