Skip to content
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

unreachable executed #10

Closed
Kuranes opened this issue May 22, 2024 · 7 comments
Closed

unreachable executed #10

Kuranes opened this issue May 22, 2024 · 7 comments

Comments

@Kuranes
Copy link

Kuranes commented May 22, 2024

on Wasm files From C++ using emscripten:
emcc ${LINK_PARAMETERS} -s EXPORTED_FUNCTIONS="['_myOwnMain','_otherCallUpdate', ...]
I get only "unreachable executed" on wasm files

Those are wasm library interfaced by js code calling wasm entry point "manually" (no main)

Would there be a way to put "wasm library" by specifying library "entry points" ?

@surma
Copy link
Owner

surma commented May 22, 2024

Are you able to share the .wasm file so I can reproduce the error? It shouldn’t matter that there is no main or anything.

@Kuranes
Copy link
Author

Kuranes commented May 23, 2024

Sorry I'll try to make a minimal repro case then if it's not supposed to happen.

@adamscott
Copy link

adamscott commented Sep 27, 2024

Hi @surma ! I'm the Web team lead developer of the @godotengine and I happen to have this same issue, when trying to debug our WASM export of the engine with debug symbols. Stripped, the template_debug build is 27.9MB, but with debug symbols, it's about 343.6MB.

It loads perfectly without debug_symbols, but it's not really interesting. It has though the unreachable executed error when loading the bigger .wasm.

Firefox 130 Chrome 129
image image

[iCloud] Here's the built files in a zip (that includes the .wasm)

Many thanks!

@surma
Copy link
Owner

surma commented Sep 28, 2024

Thanks for providing a wasm. That lets met reproduce the error. Looking into this.

The error is caused by a display function panicking (which you can actually see in your browser DevTools. I should probably surface those warnings somewhere).

Screenshot 2024-09-28 at 11 27 15

Looking into it with debug build, it seems that the demangle_cpp crate, which demangles C++ function names, is panicking for some reason. Enabling the “Raw Symbols” option in Wasmphobia will not use that crate and flamegrapg generation will suceed. That way you can continue your investigation. I will look into what’s going on there.

The error The end of an address range must not be before the beginning. is printed a lot. I’ll try and figure out whether that’s a decoding error or whether the DWARF data is faulty.

@surma
Copy link
Owner

surma commented Sep 28, 2024

I whip up a (partial) fix for this in #11.

Could you both (@Kuranes @adamscott) give it a try and confirm that it works and that the flame graph looks reasonable etc?

The error Could not extract function names for region: The end of an address range must not be before the beginning eats that wasm file without errors, so I assume there’s a bug somewhere in addr2line or similar. I don’t have time right now to investigate that deeply, so if anyone wants to help, that would be very welcome!

@adamscott
Copy link

Could you both (@Kuranes @adamscott) give it a try and confirm that it works and that the flame graph looks reasonable etc?

It seems to work alright! The signatures seems OK! I'll get back to you if there's anything wrong, but so far, so good.

Thank you so much for the fast response, greatly appreciated.

@surma
Copy link
Owner

surma commented Sep 28, 2024

Great! I’ll go ahead an merge and switch it live.

I’ll open a separate issue for the weird function error. If anyone can manage to produce a smaller wasm that triggers that error, I’d be grateful!

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

No branches or pull requests

3 participants