INCOMING_MODULE_JS_API+Pthread+Modularize don't work

[emaxx-google]

Please include the following in your bug report:

Version of emscripten/emsdk:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.48 (e967e20b4727956a30592165a3c1cde5c67fa0a8)
clang version 18.0.0 (https://github.com/llvm/llvm-project a54545ba6514802178cf7cf1c1dd9f7efbf3cde7)
Target: wasm32-unknown-emscripten
Thread model: posix

Full link command and output with -v appended:

$ em++ main.cc -pthread -s MODULARIZE=1 -s EXPORT_NAME=loadModule -s STRICT=1 -s INCOMING_MODULE_JS_API=[print,printErr] -o module.js -v
 /home/foo/env/emsdk/upstream/bin/clang --version
 "/home/foo/env/emsdk/upstream/bin/clang++" -target wasm32-unknown-emscripten -fignore-exceptions -fvisibility=default -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -D__EMSCRIPTEN_SHARED_MEMORY__=1 --sysroot=/home/foo/env/emsdk/upstream/emscripten/cache/sysroot -Xclang -iwithsysroot/include/fakesdl -Xclang -iwithsysroot/include/compat -pthread -v -matomics -mbulk-memory main.cc -c -o /tmp/emscripten_temp_fkjbjtux/main_0.o
clang version 18.0.0 (https://github.com/llvm/llvm-project a54545ba6514802178cf7cf1c1dd9f7efbf3cde7)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/foo/env/emsdk/upstream/bin
 (in-process)
 "/home/foo/env/emsdk/upstream/bin/clang-18" -cc1 -triple wasm32-unknown-emscripten -emit-obj -mrelax-all -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name main.cc -mrelocation-model static -mframe-pointer=none -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-feature +atomics -target-feature +bulk-memory -target-feature +mutable-globals -target-feature +sign-ext -target-cpu generic -target-feature +atomics -target-feature +bulk-memory -debugger-tuning=gdb -fdebug-compilation-dir=/home/bar/thread-modularized -v -fcoverage-compilation-dir=/home/bar/thread-modularized -resource-dir /home/foo/env/emsdk/upstream/lib/clang/18 -D __EMSCRIPTEN_SHARED_MEMORY__=1 -isysroot /home/foo/env/emsdk/upstream/emscripten/cache/sysroot -internal-isystem /home/foo/env/emsdk/upstream/emscripten/cache/sysroot/include/wasm32-emscripten/c++/v1 -internal-isystem /home/foo/env/emsdk/upstream/emscripten/cache/sysroot/include/c++/v1 -internal-isystem /home/foo/env/emsdk/upstream/lib/clang/18/include -internal-isystem /home/foo/env/emsdk/upstream/emscripten/cache/sysroot/include/wasm32-emscripten -internal-isystem /home/foo/env/emsdk/upstream/emscripten/cache/sysroot/include -fdeprecated-macro -ferror-limit 19 -fvisibility=default -pthread -fgnuc-version=4.2.1 -fcxx-exceptions -fignore-exceptions -fexceptions -fcolor-diagnostics -iwithsysroot/include/fakesdl -iwithsysroot/include/compat -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -o /tmp/emscripten_temp_fkjbjtux/main_0.o -x c++ main.cc
clang -cc1 version 18.0.0 based upon LLVM 18.0.0git default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/home/foo/env/emsdk/upstream/emscripten/cache/sysroot/include/wasm32-emscripten/c++/v1"
ignoring nonexistent directory "/home/foo/env/emsdk/upstream/emscripten/cache/sysroot/include/wasm32-emscripten"
#include "..." search starts here:
#include <...> search starts here:
 /home/foo/env/emsdk/upstream/emscripten/cache/sysroot/include/fakesdl
 /home/foo/env/emsdk/upstream/emscripten/cache/sysroot/include/compat
 /home/foo/env/emsdk/upstream/emscripten/cache/sysroot/include/c++/v1
 /home/foo/env/emsdk/upstream/lib/clang/18/include
 /home/foo/env/emsdk/upstream/emscripten/cache/sysroot/include
End of search list.
 /home/foo/env/emsdk/upstream/bin/wasm-ld -o module.wasm /tmp/emscripten_temp_fkjbjtux/main_0.o -L/home/foo/env/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten /home/foo/env/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/crtbegin.o -lbulkmemory -lnoexit -lc-mt-debug -ldlmalloc-mt -lcompiler_rt-mt -lc++-mt-noexcept -lc++abi-debug-mt-noexcept -lsockets-mt --fatal-warnings -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr /tmp/tmp3y6bzxknlibemscripten_js_symbols.so --import-memory --shared-memory --strip-debug --export-if-defined=main --export-if-defined=_emscripten_thread_init --export-if-defined=_emscripten_thread_exit --export-if-defined=_emscripten_thread_crashed --export-if-defined=_emscripten_tls_init --export-if-defined=pthread_self --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__start_em_lib_deps --export-if-defined=__stop_em_lib_deps --export-if-defined=__start_em_js --export-if-defined=__stop_em_js --export-if-defined=__main_argc_argv --export-if-defined=fflush --export=emscripten_stack_get_end --export=emscripten_stack_get_free --export=emscripten_stack_get_base --export=emscripten_stack_get_current --export=emscripten_stack_init --export=stackSave --export=stackRestore --export=stackAlloc --export=__errno_location --export=_emscripten_thread_free_data --export=emscripten_main_runtime_thread_id --export=emscripten_main_thread_process_queued_calls --export=_emscripten_run_on_main_thread_js --export=emscripten_stack_set_limits --export=__get_temp_ret --export=__set_temp_ret --export=__wasm_call_ctors --export=_emscripten_thread_init --export=_emscripten_thread_exit --export-table -z stack-size=65536 --initial-memory=16777216 --max-memory=16777216 --no-entry --stack-first --table-base=1
 /home/foo/env/emsdk/upstream/bin/llvm-objcopy module.wasm module.wasm --remove-section=.debug* --remove-section=producers
 /home/foo/env/emsdk/upstream/bin/wasm-emscripten-finalize --dyncalls-i64 --pass-arg=legalize-js-interface-exported-helpers module.wasm -o module.wasm --detect-features
 /home/foo/env/emsdk/node/16.20.0_64bit/bin/node /home/foo/env/emsdk/upstream/emscripten/src/compiler.js /tmp/tmp1zty6i_m.json
 /home/foo/env/emsdk/node/16.20.0_64bit/bin/node /home/foo/env/emsdk/upstream/emscripten/tools/preprocessor.js /tmp/emscripten_temp_fkjbjtux/settings.js worker.js --expandMacros

main.cc:

#include <iostream>
#include <thread>
int main() {
  std::thread t([]{
    std::cout << "Hello from thread" << std::endl;
  });
  t.detach();
}

index.html:

<script type="text/javascript" src="module.js"></script>
<script type="text/javascript">
  loadModule({
    'print': function(text) { console.log('stdout: ' + text); },
    'printErr': function(text) { console.log('stderr: ' + text); }
  });
</script>

Expected: the stdout: Hello from thread message in the JS console. Actual: no log.

P.S. The same code works after dropping -s STRICT and -s INCOMING_MODULE_JS_API parameters.

[sbc100]

Hmm... the test program is a little odd because returning from the main function will exit the whole process so that program actually doesn't print anything for me when I compile it natively on linux using clang++ or g++.

That doesn't explain the discrepancy here though...

[emaxx-google]

It's just a minimal program, written under the EXIT_RUNTIME=0 assumption - i.e. that the execution continues after main() exits. We could make it more interesting, but, yeah, the point was to show the discrepancy introduced by INCOMING_MODULE.

[sbc100]

I finally got around to looking deeper into this and there is indeed a bug here related -sSTRICT + -sINCOMING_MODULE_JS_API. I have a fix coming.

[emaxx-google]

@sbc100 Just checking if there's any possibility to get this fixed, since the PR seems to have stalled. Thanks in advance.

[sbc100]

@sbc100 Just checking if there's any possibility to get this fixed, since the PR seems to have stalled. Thanks in advance.

I'll try to pick up that PR today. In the mean time I think you can work around this by removing -sSTRICT.

[emaxx-google]

Thanks, yes, that's what I did since about a year, so it's not really a blocking issue. I was hoping to undo this hack and to benefit from the better minification before leaving my work on the application's codebase.

[sbc100]

Thanks, yes, that's what I did since about a year, so it's not really a blocking issue. I was hoping to undo this hack and to benefit from the better minification before leaving my work on the application's codebase.

A less impactful workaround could also be to explictly add noExitRuntime to -sINCOMING_MODULE_JS_API