Skip to content

TypeError when loading a wasm module #22759

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

Closed
dr-matt opened this issue Oct 17, 2024 · 6 comments · Fixed by #22760
Closed

TypeError when loading a wasm module #22759

dr-matt opened this issue Oct 17, 2024 · 6 comments · Fixed by #22760
Labels

Comments

@dr-matt
Copy link

dr-matt commented Oct 17, 2024

I ran into the following runtime error when my app tries to load a wasm module in the browser. The same code and build process worked previously, so this may be due to a more recent version of emscripten. Also this only occurrs in Release cmake build, not Debug.

TypeError: registerType registeredInstance requires argPackAdvance

This was emitted from _embind_register_void.

Before creating a MRE, I wanted to find out what this error means, as perhaps it'll help focus debugging. Googling didn't reveal anything useful. Any ideas?

Version 3.1.69:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.69 (c55ff404dbe1eb9f263c48b584d5ba627224763a)
clang version 20.0.0git (https:/github.com/llvm/llvm-project 50866e84d1da8462aeb96607bf6d9e5bbd5869c5)
Target: wasm32-unknown-emscripten
Thread model: posix

Build line from cmake:

em++ -flto --bind --closure 1 --no-entry --gc-sections -sFILESYSTEM=0 -sEXPORT_ES6=1 -sENVIRONMENT=web -sALLOW_MEMORY_GROWTH=1 --emit-tsd MyModule.d.ts @CMakeFiles/MyModule.dir/objects1.rsp -o MyModule.js @CMakeFiles/MyModule.dir/linkLibs.rsp
@brendandahl
Copy link
Collaborator

I was able to reproduce with a small example and doing emcc --closure 1 -lembind main.cpp -o a.out.js. It looks like a regression from #22413. Closure is minifying argPackAdvance, but we're still checking for the string name.

Aside: The error is coming from an assertion, which should be disabled with any optimization level of -O<x>. Are you intentionally enabling assertions for your release build?

@dr-matt
Copy link
Author

dr-matt commented Oct 17, 2024

@brendandahl thanks for looking into this. I did not explicitly enable assertions in the build, and as far as I know the Release cmake build uses -O2. So from your description it seems strange that the debug build works while the release build does not.

@brendandahl
Copy link
Collaborator

Does your debug build enable closure?

@brendandahl
Copy link
Collaborator

Also, from the command you posted above there doesn't appear to be any -O flags.

@dr-matt
Copy link
Author

dr-matt commented Oct 17, 2024

When I explicitly add -sASSERTIONS=0 to the release build, then it works. I thought that was the default value - I am not setting it explicitly.

In debug build, this is the line:

em++ -flto --bind --closure 1 --no-entry --gc-sections -sFILESYSTEM=0 -sEXPORT_ES6=1 -sENVIRONMENT=web -sALLOW_MEMORY_GROWTH=1 -g2 -sASSERTIONS=2 -sNO_DISABLE_EXCEPTION_CATCHING --emit-tsd MyModule.d.ts @CMakeFiles/MyModule.dir/objects1.rsp -o MyModule.js @CMakeFiles/MyModule.dir/linkLibs.rsp

You're right about -O2 not being there, that's strange. I'll look into why optimizations are no longer being turned on via cmake.

@dr-matt
Copy link
Author

dr-matt commented Oct 18, 2024

@brendandahl thanks for addressing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants
@brendandahl @dr-matt and others