InternalError: too much recursion,__emscripten_pthread_data_constructor on EMSDK 2.0.5 (2.0.3 was fine)

[rsielken]

We updated from EMSDK 2.0.3 to 2.0.5 to pick up the fix from #12035. The test case from 12035 was verified as fixed. However, our main application builds cleanly but gets this at startup all the time now:

Starting WASMCanvas ui-bundle-6-a8f04d9ea6493393a263.js:8:1954
unhandled exception: InternalError: too much recursion,__emscripten_pthread_data_constructor@https://localhost:8080/9d5dca55e9aecddcc4c58e7daf3efbbd753769ba.wasm:wasm-function[135800]:0x8e39652
__wasm_call_ctors@https://localhost:8080/9d5dca55e9aecddcc4c58e7daf3efbbd753769ba.wasm:wasm-function[576]:0x5b8d7
makeWrapper/abortWrapperCache[original]@https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1771:21
createExportWrapper/<@https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1754:20
initRuntime@https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:2691:29
initPthreadsJS@https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:2004:10
__emscripten_pthread_data_constructor@https://localhost:8080/9d5dca55e9aecddcc4c58e7daf3efbbd753769ba.wasm:wasm-function[135800]:0x8e39652
__wasm_call_ctors@https://localhost:8080/9d5dca55e9aecddcc4c58e7daf3efbbd753769ba.wasm:wasm-function[576]:0x5b8d7
makeWrapper/abortWrapperCache[original]@https://lo…
ui-bundle-6-a8f04d9ea6493393a263.js:8:2192
error { target: Window, isTrusted: true, message: "RuntimeError: abort(unhandled exception: InternalError: too much recursion,__emscripten_pthread_data_constructor@https://localhost:8080/9d5dca55e9aecddcc4c58e7daf3efbbd753769ba.wasm:wasm-function[135800]:0x8e39652\n__wasm_call_ctors@https://localhost:8080/9d5dca55e9aecddcc4c58e7daf3efbbd753769ba.wasm:wasm-function[576]:0x5b8d7\nmakeWrapper/abortWrapperCache[original]@https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1771:21\ncreateExportWrapper/<@https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1754:20\ninitRuntime@https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:2691:29\ninitPthreadsJS@https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:2004:10\n__emscripten_pthread_data_constructor@https://localhost:8080/9d5dca55e9aecddcc4c58e7daf3efbbd753769ba.wasm:wasm-function[135800]:0x8e39652\n__wasm_call_ctors@https://localhost:8080/9d5dca55e9aecddcc4c58e7daf3efbbd753769ba.wasm:wasm-function[576]:0x5b8d7\nmakeWrapper/abortWrapperCache[…", filename: "https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js", lineno: 1720, colno: 10, error: RuntimeError, srcElement: Window, currentTarget: Window, eventPhase: 2, … }
ui-bundle-6-a8f04d9ea6493393a263.js:8:2192
Uncaught RuntimeError: abort(unhandled exception: InternalError: too much recursion,__emscripten_pthread_data_constructor@https://localhost:8080/9d5dca55e9aecddcc4c58e7daf3efbbd753769ba.wasm:wasm-function[135800]:0x8e39652
__wasm_call_ctors@https://localhost:8080/9d5dca55e9aecddcc4c58e7daf3efbbd753769ba.wasm:wasm-function[576]:0x5b8d7
makeWrapper/abortWrapperCache[original]@https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1771:21
createExportWrapper/<@https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1754:20
initRuntime@https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:2691:29
initPthreadsJS@https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:2004:10
__emscripten_pthread_data_constructor@https://localhost:8080/9d5dca55e9aecddcc4c58e7daf3efbbd753769ba.wasm:wasm-function[135800]:0x8e39652
__wasm_call_ctors@https://localhost:8080/9d5dca55e9aecddcc4c58e7daf3efbbd753769ba.wasm:wasm-function[576]:0x5b8d7
makeWrapper/abortWrapperCache[original]@http…
    abort https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1720
    original https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1776
    createExportWrapper https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1754
    func https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:14444
    callRuntimeCallbacks https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:2420
    initRuntime https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1535
    doRun https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:16759
    run https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:16774
    runCaller https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:16721
    removeRunDependency https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1700
    processPackageData https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:304
    onsuccess https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:226
    onsuccess https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:225
    cacheRemotePackage https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:216
    runWithFS https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:322
    onload https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:121
    fetchRemotePackage https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:118
    runWithFS https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:321
    onsuccess https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:245
    checkCachedPackage https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:242
    runWithFS https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:314
    onsuccess https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:198
    openDatabase https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:196
    runWithFS https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:313
    callRuntimeCallbacks https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:2409
    preRun https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1525
    run https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:16752
    runCaller https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:16721
    removeRunDependency https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1700
    receiveInstance https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1859
    onmessage https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:2822
    loadWasmModuleToWorker https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:2796
    receiveInstance https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1858
    receiveInstance https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1857
    receiveInstantiatedSource https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1871
    promise callback*instantiateAsync/< https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1887
    promise callback*instantiateAsync https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1885
    createWasm https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1906
    <anonymous> https://localhost:8080/4cd7cbdc50464440e95a366354ec81c95ae1653d.js:15035
4cd7cbdc50464440e95a366354ec81c95ae1653d.js:1720:10

I get this same error and stack in Firefox 70, 78 and 80 which were all working with 2.0.3. Chrome 85 doesn't give me the stack; I just get "Aw, Snap!" with error code 4.

I suspect this is related to the pthread handling changes for 12035, but I don't have any proof of that and it could be related to other fixes.

Here are the settings we are building with (unchanged between us building and running successfully on 2.0.3 and failing to run on 2.0.5):

-s USE_PTHREADS=1 -s PROXY_TO_PTHREAD=1 -s PTHREAD_POOL_SIZE=8 -s FETCH=1 -s FETCH_SUPPORT_INDEXEDDB=0 -s FULL_ES2=1 -s USE_SDL=2 -s USE_SDL_TTF=2 -s USE_FREETYPE=2 -s USE_LIBPNG=1 -s DISABLE_EXCEPTION_CATCHING=0 -s INITIAL_MEMORY=268435456 -s ALLOW_MEMORY_GROWTH=1 -s FORCE_FILESYSTEM=1 -s ERROR_ON_UNDEFINED_SYMBOLS=0 -s OFFSCREEN_FRAMEBUFFER=1 -s DEMANGLE_SUPPORT=1 -s ABORT_ON_WASM_EXCEPTIONS=1

The test case from 12035 allocates pthreads and then uses more pthreads forcing additional pthread allocation, and that still works. But this error seems to be related to pthread allocation at the beginning (we have barely started running), so I'm not sure what else to try in a test case to recreate this. Any ideas on what changed to cause this issue or what steps need to be added to the test case to hit the error?

[sbc100]

Looks related to ABORT_ON_WASM_EXCEPTIONS. if you drop that flag does it start working?

[tklajnscek]

Yeah, looks like you hit this which causes wrong functions to be called:
#12441

Does it work if you take preamble.js from that PR?

[tklajnscek]

Yeah, it looks like you hit this which causes wrong functions to be called: #12441

Does it work if you take preamble.js from that PR?

[rsielken]

I can confirm that EMSDK 2.0.5 (I know 2.0.6 is out but we hadn't changed again to 2.0.6 yet) with the preamble.js from #12441 (from Monday) does fix this. I tried both with and without ABORT_ON_WASM_EXCEPTIONS=1, and that didn't matter - it was the preamble.js that mattered.

[tklajnscek]

OK, that's great, hope it gets merged soon.

It should only fail with ABORT_ON_WASM_EXCEPTIONS=1 though as that code path in preamble.js that I changed won't get hit if ABORT_ON_WASM_EXCEPTIONS = 0.

Can you double check that actually passed in 0 correctly (or just omit the whole thing - it defaults to 0). You can look at the compiled output .js file - you shouldn't see makeAbortWrapper in it at all if ABORT_ON_WASM_EXCEPTIONS is 0.

[rsielken]

What I was trying to say was with the new preamble.js, the value of ABORT_ON_WASM_EXCEPTIONS didn't matter - it worked with 1 and with 0 (knowing that the makeAbortWrapper wasn't there with 0). I didn't expect 0 to be a problem - I was just checking in case there was some side effect that was caused.

I did go back and reconfirm that we didn't have the problem with the old preamble.js and ABORT_ON_WASM_EXCEPTIONS omitted (zero). We only had the problem with the old preamble.js and ABORT_ON_WASM_EXCEPTIONS of 1.

[tklajnscek]

Ah ok, great, the PR fixes it then! Thanks for taking the time to test it :)

[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.

[rsielken]

I confirmed that we are using ABORT_ON_WASM_EXCEPTIONS=1 (and have been for quite a while) and it is working. This can be closed, but should be closed as fixed OR dup'ed against #12441 (probably dup'ed).