INCOMING_MODULE_JS_API+Pthread+Modularize don't work #20636

emaxx-google · 2023-11-07T00:13:43Z

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.

The text was updated successfully, but these errors were encountered:

sbc100 · 2023-11-07T01:03:58Z

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 · 2023-11-07T01:36:31Z

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 · 2024-09-09T17:42:45Z

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.

…me is not referenced Fixes: emscripten-core#20636

…me is not referenced Essentially the `keepRuntimeAlive` was relying on the `noExitRuntime` variable being set based on `EXIT_RUNTIME` but when `noExitRuntime` was absent the `EXIT_RUNTIME` settings was being ignored and the runtime was exiting even though `EXIT_RUNTIME=0` was set (the default). Fixes: emscripten-core#20636

emaxx-google · 2024-10-21T15:51:06Z

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

sbc100 · 2024-10-21T16:50:09Z

@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 · 2024-10-21T16:54:32Z

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 · 2024-10-21T17:01:51Z

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

…me is not referenced Essentially the `keepRuntimeAlive` was relying on the `noExitRuntime` variable being set based on `EXIT_RUNTIME` but when `noExitRuntime` was absent the `EXIT_RUNTIME` settings was being ignored and the runtime was exiting even though `EXIT_RUNTIME=0` was set (the default). Fixes: emscripten-core#20636

…me is not referenced (#22542) Essentially the `keepRuntimeAlive` was relying on the `noExitRuntime` variable being set based on `EXIT_RUNTIME` but when `noExitRuntime` was absent the `EXIT_RUNTIME` settings was being ignored and the runtime was exiting even though `EXIT_RUNTIME=0` was set (the default). Fixes: #20636

emaxx-google mentioned this issue Jan 24, 2024

INCOMING_MODULE_JS_API requires attributes that aren't used #21167

Closed

emaxx-google mentioned this issue Apr 16, 2024

"user callback triggered after runtime exited or application aborted" started on 3.1.47 #20457

Closed

sbc100 added a commit to sbc100/emscripten that referenced this issue Sep 9, 2024

Fix keepRuntimeAlive in the case where EXIT_RUNTIME=0 and noExitRunti…

67c9917

…me is not referenced Fixes: emscripten-core#20636

sbc100 mentioned this issue Sep 9, 2024

Fix keepRuntimeAlive in the case where EXIT_RUNTIME=0 and noExitRuntime is not referenced #22542

Merged

sbc100 closed this as completed in #22542 Oct 21, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

INCOMING_MODULE_JS_API+Pthread+Modularize don't work #20636

INCOMING_MODULE_JS_API+Pthread+Modularize don't work #20636

emaxx-google commented Nov 7, 2023 •

edited

Loading

sbc100 commented Nov 7, 2023

emaxx-google commented Nov 7, 2023

sbc100 commented Sep 9, 2024

emaxx-google commented Oct 21, 2024 •

edited

Loading

sbc100 commented Oct 21, 2024

emaxx-google commented Oct 21, 2024

sbc100 commented Oct 21, 2024

INCOMING_MODULE_JS_API+Pthread+Modularize don't work #20636

INCOMING_MODULE_JS_API+Pthread+Modularize don't work #20636

Comments

emaxx-google commented Nov 7, 2023 • edited Loading

sbc100 commented Nov 7, 2023

emaxx-google commented Nov 7, 2023

sbc100 commented Sep 9, 2024

emaxx-google commented Oct 21, 2024 • edited Loading

sbc100 commented Oct 21, 2024

emaxx-google commented Oct 21, 2024

sbc100 commented Oct 21, 2024

emaxx-google commented Nov 7, 2023 •

edited

Loading

emaxx-google commented Oct 21, 2024 •

edited

Loading