Asyncify ignore & debug flag

[stelcheck]

Edit: for point two --profiling seems to be helping digging out the issue, but I'm still a bit confused as to why debugging flag would make things work.

I am currently working on a codebase where I ASYNCIFY_IGNORE_INDIRECT then ASYNC_ADD the functions/methods needed. This works as intended when -g3 or higher is set, but fails with:

(index):1 exception thrown: RuntimeError: function signature mismatch,RuntimeError: function signature mismatch
    at emscripten::internal::Invoker<void, unsigned int>::invoke(void (*)(unsigned int), unsigned int) (http://localhost:8000/byuu-web.wasm:wasm-function[3898]:0x23f8a5)
    at ret.<computed> (http://localhost:8000/byuu-web.js:9126:35)
    at Object.finishContextSwitch (http://localhost:8000/byuu-web.js:9309:11)
    at Object.trampoline (http://localhost:8000/byuu-web.js:9283:20)
    at Object.ret.<computed> [as dynCall_v] (http://localhost:8000/byuu-web.js:9138:30)
    at browserIterationFunc (http://localhost:8000/byuu-web.js:5492:30)
    at Object.runIter (http://localhost:8000/byuu-web.js:5605:13)
    at Browser_mainLoop_runner (http://localhost:8000/byuu-web.js:5544:26)

My questions are:

1. Is it possible that Asyncify relies on debugging information?
2. What would be the best method to go about to investigate these kind of issues?

[stelcheck]

Probably unrelated, but AL.currentCtx also never gets set and the audio seems to be disabled.

Edit: it appears that some C++ class pointers are not set to null by default when using Asyncify (in my code); is this an expected side effect?

[stelcheck]

After digging a bit deeper, it appears to be a similar situation as described in #10941

I notice the stack differs between the first and second iteration (stack trace at the beginning of the main loop):

first iteration

running Error
    at 86807 (http://localhost:8000/byuu-web.js:1:14186)
    at _emscripten_asm_const_iii (http://localhost:8000/byuu-web.js:1:21722)
    at run() (http://localhost:8000/byuu-web.wasm:wasm-function[1380]:0xaa6f9)
    at thread_entry (http://localhost:8000/byuu-web.wasm:wasm-function[782]:0x434fa)
    at ret.<computed> (http://localhost:8000/byuu-web.js:1:178850)
    at Object.Module.dynCall_v (http://localhost:8000/byuu-web.js:1:256330)
    at browserIterationFunc (http://localhost:8000/byuu-web.js:1:104810)
    at Object.runIter (http://localhost:8000/byuu-web.js:1:107530)
    at Browser_mainLoop_runner (http://localhost:8000/byuu-web.js:1:106013)

second iteration

running Error
    at 86807 (http://localhost:8000/byuu-web.js:1:14186)
    at _emscripten_asm_const_iii (http://localhost:8000/byuu-web.js:1:21722)
    at run() (http://localhost:8000/byuu-web.wasm:wasm-function[1380]:0xaa6f9)
    at thread_entry (http://localhost:8000/byuu-web.wasm:wasm-function[782]:0x434fa)
    at Object.ret.<computed> [as dynCall_v] (http://localhost:8000/byuu-web.js:1:178850)
    at browserIterationFunc (http://localhost:8000/byuu-web.js:1:104810)
    at Object.runIter (http://localhost:8000/byuu-web.js:1:107530)
    at Browser_mainLoop_runner (http://localhost:8000/byuu-web.js:1:106013)

Notice how Object.ret.<computed> [as dynCall_v] now seems to be replacing two similar calls in the first iteration's stack. What is also confusing is that thread_entry hasn't been called at this point (it's the endpoint used by emscripten_fiber_swap), so I'm not entirely sure why it pops up in both stacks (since run should get called by emscripten_set_main_loop).

I also noticed that I can fix the issue by adding "emscripten*" to ASYNCIFY_ONLY or ASYNCIFY_ADD.

I'm still not sure why initial values some object attributes are non-null and why -g4 solves the issue however.

[kripken]

Perhaps reading the code at the locations where the stack traces differ can help understand this. It does seem puzzling why the trace would change.

If nothing else works, I'd try to reduce this to a small testcase. That often helps figure things out, and if not, you can submit it as a testcase here which we can debug.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.