Bug 184830
| Summary: | Mono regression suite crashes with jsc in dyld`__abort_with_payload | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Rodrigo Kumpera <rokumper> |
| Component: | WebAssembly | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | ap, fpizlo, jfbastien, keith_miller, mark.lam, msaboff, rmorisset, saam |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Mac | ||
| OS: | macOS 10.13 | ||
Rodrigo Kumpera
Using nightly build v230841 through jsvu.
When I try to run mono's regression suite with jsc, it aborts early on.
Running under LLDB I get a really weird backtrace:
```
* thread #1, stop reason = signal SIGABRT
* frame #0: 0x000000010007a216 dyld`__abort_with_payload + 10
frame #1: 0x0000000100079b88 dyld`abort_with_payload_wrapper_internal + 89
frame #2: 0x0000000100079bb5 dyld`abort_with_payload + 9
frame #3: 0x000000010004d482 dyld`dyld::halt(char const*) + 354
frame #4: 0x0000000100050533 dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 8004
frame #5: 0x000000010004a3d4 dyld`dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 453
frame #6: 0x000000010004a1d2 dyld`_dyld_start + 54
```
How to reproduce: Follow the instructions on https://github.com/mono/mono/blob/master/sdks/wasm/README.md and run `make run-jsc-mini`.
I can provide a zip with all the required files if so desired.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
JF Bastien
That's pretty weird!
Alexey Proskuryakov
Re-titling to match description. This is unlikely to be a WebKit bug.
As you are already in lldb, please check the reason string that's being passed to abort_with_payload(), that will explain why the process can't be launched. One possibility is that the test suite confuses JavaScriptCore versions in /System/Library/Frameworks and /System/Library/StagedFrameworks somehow - if the crash is even related to JavaScriptCore in any way.
Rodrigo Kumpera
Hey Alexey Proskuryakov,
As it turns out, JSC plays a lot of hw traps tricks that confuses the hell out of lldb.
So, after some creative debugging I confirm this is crashing in the NaturalLoops pass. Here's the actual crash backtrace:
```
* thread #9, name = 'WTF::AutomaticThread', stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
* frame #0: 0x000000010f5a0f0e JavaScriptCore`WTF::NaturalLoops<JSC::B3::CFG>::NaturalLoops(JSC::B3::CFG&, WTF::Dominators<JSC::B3::CFG>&, bool) + 3118
frame #1: 0x000000010f58ed77 JavaScriptCore`JSC::B3::Procedure::naturalLoops() + 71
frame #2: 0x000000010f52f78c JavaScriptCore`JSC::B3::ensureLoopPreHeaders(JSC::B3::Procedure&) + 28
frame #3: 0x000000010f53b995 JavaScriptCore`JSC::B3::hoistLoopInvariantValues(JSC::B3::Procedure&) + 53
frame #4: 0x000000010f53b814 JavaScriptCore`JSC::B3::generateToAir(JSC::B3::Procedure&) + 196
frame #5: 0x000000010f53b729 JavaScriptCore`JSC::B3::prepareForGeneration(JSC::B3::Procedure&) + 41
frame #6: 0x000000010fff55b9 JavaScriptCore`JSC::Wasm::parseAndCompile(JSC::Wasm::CompilationContext&, unsigned char const*, unsigned long, JSC::Wasm::Signature const&, WTF::Vector<JSC::Wasm::UnlinkedWasmToWasmCall, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, JSC::Wasm::ModuleInformation const&, JSC::Wasm::MemoryMode, JSC::Wasm::CompilationMode, unsigned int, JSC::Wasm::TierUpCount*, void* (*)(JSC::ExecState*, JSC::Wasm::ExceptionType, JSC::Wasm::Instance*)) + 1161
frame #7: 0x0000000110031d69 JavaScriptCore`JSC::Wasm::OMGPlan::work(JSC::Wasm::Plan::CompilationEffort) + 185
frame #8: 0x00000001100524a4 JavaScriptCore`JSC::Wasm::Worklist::Thread::work() + 52
frame #9: 0x000000010f47a2a4 JavaScriptCore`WTF::Function<void ()>::CallableWrapper<WTF::AutomaticThread::start(WTF::AbstractLocker const&)::$_0>::call() + 292
frame #10: 0x000000010f4b97f1 JavaScriptCore`WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) + 225
frame #11: 0x000000010f4bb1f9 JavaScriptCore`WTF::wtfThreadEntryPoint(void*) + 9
frame #12: 0x00007fff673f8661 libsystem_pthread.dylib`_pthread_body + 340
frame #13: 0x00007fff673f850d libsystem_pthread.dylib`_pthread_start + 377
frame #14: 0x00007fff673f7bf9 libsystem_pthread.dylib`thread_start + 13
```
This is a dupe of https://bugs.webkit.org/show_bug.cgi?id=184829
Sorry for filling multiple issues, it wasn't originally clear to me that they were the same.
*** This bug has been marked as a duplicate of bug 184829 ***