search

emscripten-core / emscripten

Emscripten: An LLVM-to-WebAssembly Compiler
Other
25.91k stars 3.32k forks source link

Help with debugging wasm and page generated with Emscripten 3.1.68 #22733

Closed netolcc06 closed 1 month ago

netolcc06 commented 1 month ago

Hi everyone,

I'd like to have some guidance on how to properly debug one issue I'm having.

A few months ago I worked on using Emscripten to generate a wasm version of cvc5. At that time I was using Emscripten v3.1.18 and managed to produce successful builds and pages by setting the HTML option. Flags such as -s EXPORTED_RUNTIME_METHODS='["ccall","cwrap"]' -s ENVIRONMENT=web -s EXPORTED_FUNCTIONS=_main -s INVOKE_RUN=1 -s EXIT_RUNTIME=0 -s INCOMING_MODULE_JS_API=argument also worked fine.

Recently I tried to use Emscripten 3.1.68 with the same flags, but the generated page just throws a generic message Uncaught (in promise) 868912 when it starts. I thought the issue could be related to changes in cvc5's build system, but nothing has changed there - and old versions of the program that used to produce valid wasm + html pages present the same behaviour if built with 3.1.68. From what I checked from Emscripten docs, compilation instructions seem to be the same as a few months back though.

With that said, what is the best way of moving forward here and debug what is happening with the page? I want to figure out what actually got broken with the most recent version and adjust my source code, if necessary, in order to produce valid wasm binaries.

Thanks in advance!

kripken commented 1 month ago

For a regression like this, bisection is often a fast way to find what caused the issue.

sbc100 commented 1 month ago

Also, building with without optimization (i.e. with -O0 which is the default) and/or with -sASSERTIONS can help a lot.

When you get the Uncaught (in promise) I would expect some kind of backtrace that might give you a clue as to what the issue is.

netolcc06 commented 1 month ago

Ok. Apart some missing flags I need to add, the ultimate exception is unsupported syscall: __syscall_prlimit64.

I wonder why this isn't an issue with old versions.

sbc100 commented 1 month ago

Ok. Apart some missing flags I need to add, the ultimate exception is unsupported syscall: __syscall_prlimit64.

I don't think the unsupported syscall: __syscall_prlimit64 message is the direct cause. That just means that syscall is not fully implemented, but it still returns and your program continues, to the actual exception is something else. Put another way, the "unsuppoered syscall" message is just a console warning, and nothing more.