Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/v8/v8/+/a9d9001810aef2b3ad9487b4e9cb5ae766381abc ([wasm] Fix up mips & WasmCodeManager).

If this is incorrect, please remove the owner and apply the Test-Predator-Wrong-CLs label.

This is reproducible also with: 

d8 --wasm-lazy-compilation test/mjsunit/mjsunit.js test/mjsunit/wasm/indirect-tables.js

and is reproducible in both gc and non-gc wasm.

This very likely surfaced after https://chromium-review.googlesource.com/c/v8/v8/+/826030. Fixing the issue of indirect calls through exported tables means that now lazy compile sees 2 wasm frames calling each other (it can't see the wasm_to_wasm call, those don't create a frame). It then assumes this must be a direct call, or it seeks a direct wasm-to-js call through the caller's code (it won't find one.).

Added Clemens, perhaps he has some more thoughts on fixing lazy compile in the presence of indirect calls to wasm_to_wasm.

An idea: if caller and callee are wasm (callee could be wasm_to_js, too - indirect call to exported import), we check their instances. If they aren't the same, we know there's a wasm_to_wasm in between. We'll have to patch that one, then. For off-the-gc, that's easy to find - NativeModule::GetExportedWrapper. For the gc case, we'll probably need to create a similar service on WasmCompiledModule? Alternatively, we can add to the deopt data, but that's likely going to be a bug farm, there are lots of assumptions about that thing's size and divisibility to 2.

I suspect we don't want wasm_to_wasm to create a frame.

Any other ideas?

re-assigning, it's a lazy compilation issue

Thanks, I will take a look whenever I have free cycles.
Lowering priority, as this requires the '--wasm-lazy-compilation' flag.

ClusterFuzz has detected this issue as fixed in range 52435:52436.

Detailed report: https://clusterfuzz.com/testcase?key=5555636682358784

Fuzzer: ochang_js_fuzzer
Job Type: linux_asan_d8_v8_mipsel_dbg
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x0000001c
Crash State:
  v8::internal::wasm::LazyCompilationOrchestrator::CompileDirectCall
  v8::internal::wasm::CompileLazy
  v8::internal::__RT_impl_Runtime_WasmCompileLazy
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_d8_v8_mipsel_dbg&range=50036:50037
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_d8_v8_mipsel_dbg&range=52435:52436

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5555636682358784

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 5555636682358784 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.