-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RangeError: Maximum call stack size exceeded
when building libopenmpt test suite with -s WASM=2
or -s WASM=0
#17897
Comments
That does seem odd that it regressed since |
Running bisect right now. |
As we are compiling with I do not have a setup to run runtime performance numbers, but I can provide a size comparison for libopenmpt (not test suite) (with emscripten 3.1.22):
I would call at least the size difference not really significant. We build everything with -flto. |
|
RangeError: Maximum call stack size exceeded
when building libopenmpt test suite with -s WASM=2
RangeError: Maximum call stack size exceeded
when building libopenmpt test suite with -s WASM=2
or -s WASM=0
It sounds like It looks like there is an FAQ entry for how to deal with running out of stack: https://emscripten.org/docs/getting_started/FAQ.html#why-do-i-get-a-stack-size-error-when-optimizing-rangeerror-maximum-call-stack-size-exceeded-or-similar. Can you confirm that adding that flag fixes the issue? |
…ipten#17897> by passing -fno-inline-functions when using -s WASM=2 or -s WASM=0. git-svn-id: https://source.openmpt.org/svn/openmpt/trunk/OpenMPT@17908 56274372-70c3-4bfc-bfc3-4c3a0b034d27
[Fix] build: Makefile: Emscripten: Work-around <emscripten-core/emscripten#17897> by passing -fno-inline-functions when using -s WASM=2 or -s WASM=0. ........ git-svn-id: https://source.openmpt.org/svn/openmpt/branches/OpenMPT-1.29@17910 56274372-70c3-4bfc-bfc3-4c3a0b034d27
[Fix] build: Makefile: Emscripten: Work-around <emscripten-core/emscripten#17897> by passing -fno-inline-functions when using -s WASM=2 or -s WASM=0. ........ git-svn-id: https://source.openmpt.org/svn/openmpt/branches/OpenMPT-1.30@17909 56274372-70c3-4bfc-bfc3-4c3a0b034d27
I have already added I will try setting the stack size as a work-around tomorrow. Is there a way to set that from the |
You might be able to set |
Guess I still found some time today.
For libopenmpt, I will stick to the |
Any update on this one? It is frankly quite annoying that, over time, I continuously have to add more and more non-standard compiler flags as work-arounds for emscripten because the default configuration of emscripten appears to less and less be able to even compile a moderately-sized C++ project successfully. IMHO, this is kind-of a bad sign for emscripten. |
Sorry you were negatively effected by the I'm also curious why nobody else has reported this. That could be because most folks don't use wasm2js, or it could be because there is something about your input program that is unique. I would love to be able to replicate this failure in test when landing the fix but I'm also OK with just landing since it seems like great prophylactic with little downside. |
On windows the default stack size is still limited to 1MB in older versions of node. See nodejs/node#43632 which made it into v19.0.0. Fixes: emscripten-core#17897
On windows the default stack size is still limited to 1MB in older versions of node. See nodejs/node#43632 which made it into v19.0.0. Fixes: #17897
Version of emscripten/emsdk:
Failing command line in full:
When building libopenmpt test suite (https://github.com/OpenMPT/openmpt/) with
make CONFIG=emscripten TEST=1 ONLY_TEST=1 EMSCRIPTEN_TARGET=all
(this implies emscripten specific options-Oz -flto -s WASM=2 -s LEGACY_VM_SUPPORT=1 -Wno-transpile -s DISABLE_EXCEPTION_CATCHING=0 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s ERROR_ON_MISSING_LIBRARIES=1 -s EXPORT_NAME="'libopenmpt'"
), we are seeing:Emscripten 3.1.21 worked fine, so this is a regression.
Building libopenmpt itself and not the test suite works also fine ('make CONFIG=emscripten TEST=0 EMSCRIPTEN_TARGET=all`).
Building the test suite with
-s WASM=1
instead of-s WASM=2 -s LEGACY_VM_SUPPORT=1 -Wno-transpile
works also fine (make CONFIG=emscripten TEST=1 ONLY_TEST=1 EMSCRIPTEN_TARGET=wasm
).Even if it should not be easy to fix on the emscripten side, I would appreciate hints about how I could try to work-around the issue on the libopenmpt side.
The text was updated successfully, but these errors were encountered: