test_pthread_join_and_asyncify fails on asan/lsan

[aheejin]

asan.test_pthread_join_and_asyncify fails with the message

worker.js onmessage() captured an uncaught exception: RuntimeError: null function or function signature mismatch
RuntimeError: null function or function signature mismatch
    at test_pthread_join_and_asyncify.wasm.__asan::asan_thread_start(void*) (wasm://wasm/test_pthread_join_and_asyncify.wasm-00a319e6:wasm-function[571]:0x18984)
    at Object.invokeEntryPoint (/usr/local/google/home/aheejin/emscripten/out/test/test_pthread_join_and_asyncify.js:1465:37)
    at handleMessage (/usr/local/google/home/aheejin/emscripten/out/test/test_pthread_join_and_asyncify.worker.js:164:35)
    at MessagePort.<anonymous> (/usr/local/google/home/aheejin/emscripten/out/test/test_pthread_join_and_asyncify.worker.js:29:38)
    at [nodejs.internal.kHybridDispatch] (node:internal/event_target:810:20)
    at exports.emitMessage (node:internal/per_context/messageport:23:28)

lsan.test_pthread_join_and_asyncify fails in a similar way with only the function name (asan_thread_start) different.

This doesn't look related to #21663 because they fail without it too.

Our Test suite CI (https://ci.chromium.org/ui/p/emscripten-releases/builders/luci.emscripten-releases.ci/linux-test-suites) doesn't detect it because this test is only enabled with Node Canary and skipped in the CI.

---

I'm not very familiar with how JSPI and sanitizers work, but looking at the generated code, within asan_thread_start, there is a call_indirect. Here (type $3) is (param i32) (result i32)

   (call_indirect (type $3)
    (i32.load offset=12
     (local.get $1)
    )
    (i32.load offset=8
     (local.get $1)
    )
   )

which I think is supposed to call run_thread here:

emscripten/test/core/test_pthread_join_and_asyncify.c

Line 25 in 9293ec8

pthread_create(&id, NULL, run_thread, NULL);

emscripten/test/core/test_pthread_join_and_asyncify.c

Line 17 in 9293ec8

EMSCRIPTEN_KEEPALIVE void *run_thread(void *args) {

And run_thread's type is (param i32) (result i32).

But the actual function called by that call_indirect, which is in the elem section, is a function named $export$run_thread. And its signature is (param $susp externref) (param $0 i32) (result i32). (Note that there is an additional externref param)

I think this is the reason why it fails with the "signature mismatch" error. I'm not familiar with how JSPI works, so I'm not sure why run_thread is exported with a different signature.

cc @brendandahl

[brendandahl]

A lot of this will be changing with the new JSPI spec changes that don't require modification of the Wasm file. It's probably not worth looking into this issue for the time being, but revist when we update.