emscripten-core/emscripten

"Cannot convert 14 to a BigInt" error introduced in 4.0.11

Opened this issue · 8 comments

DerThorsten commented

Emscripten 4.0.11 introduced an issue when using the following flags together:

  • embind
  • WASM_BIGINT
  • fexceptions
  • MAIN_MODULE

Code like that

emscripten::val obj = emscripten::val::object();
obj.set("value",  uint8_t(42));

will fail at runtime with

emdebug.js:1 Uncaught (in promise) TypeError: Cannot convert 14 to a BigInt
    at invoke_diiiii (emdebug.js:1:591968)
    at emdebug.wasm:0x92103
    at invoke_viii (emdebug.js:1:591634)
    at emdebug.wasm:0x91fbe
    at emdebug.wasm:0x91f6d
    at Object.return_object (eval at createJsInvoker (emdebug.js:1:118653), <anonymous>:4:10)
    at main (index.html:16:31)

To reproduce one can use the following:

#include <emscripten/bind.h>

EMSCRIPTEN_BINDINGS(my_module)
{
    emscripten::function("return_object",   +[](
    ){
        emscripten::val obj = emscripten::val::object();
        obj.set("value",  uint8_t(42));
        return obj;
    });
}

Cli:

emcc main.cpp -o emdebug.js \
    -fexceptions \
    -fPIC \
    -s MODULARIZE=1 \
    -s MAIN_MODULE=1 \
    -lembind \
    -s WASM_BIGINT=1 \
    -v

Html / Js

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Minimal HTML</title>
</head>
<body>
    <script src="emdebug.js"></script>
    <script>
        async function main() {
            emdebug = await Module();
            console.log("emdebug loaded",emdebug)

            let obj = emdebug.return_object();
            console.log("obj",obj);
            console.log("obj.value",obj.value);
        }
        main();

    </script>
</body>
</html>

When any of the above mentioned flags are removed / changed, the error disappears. Ie it realy needs a main module with exceptions and wasm-bigint to trigger the issue.

kripken commented

The changelog mentions #24678 in that release, which altered 64-bit handling in embind. @RReverser could that explain this?

If not, then @DerThorsten I would recommend bisection

RReverser commented

Oh damn, that looks pretty bad, although very specific combination of flags would explain why CI hasn't caught it.

#24678 does seem like a likely candidate, worth trying with just that patch reverted locally to see if the issue persists.

DerThorsten commented

tiny corrigendum, it needs also -O3 to fail

ie: failing:

emcc main.cpp -o emdebug.js \
    -fexceptions \
    -fPIC \
    -s MODULARIZE=1 \
    -s MAIN_MODULE=1 \
    -lembind \
    -s WASM_BIGINT=1 \
    -O3

working:

emcc main.cpp -o emdebug.js \
    -fexceptions \
    -fPIC \
    -s MODULARIZE=1 \
    -s MAIN_MODULE=1 \
    -lembind \
    -s WASM_BIGINT=1 \
    -O2

I'll do a proper bisection tomorrow but I would also suspect #24678

RReverser commented

That's such a strange and specific combination...

DerThorsten commented

bisecting on the emscripten release repo yields the following results:

65aa70c7fbf0a9560ad92efcfe98f1bdc330f2f4 is the first bad commit
commit 65aa70c7fbf0a9560ad92efcfe98f1bdc330f2f4
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date:   Sat Jun 21 04:36:30 2025 -0700

    Roll emscripten from 380a5a105c9e to 357a773cc351 (31 revisions)

    https://chromium.googlesource.com/external/github.com/emscripten-core/emscripten.git/+log/380a5a105c9e..357a773cc351

    2025-06-21 me@rreverser.com [embind] Allow Closure to compress registerType methods (#24610)
    2025-06-19 me@rreverser.com [emval] Prevent creating lvalue refs from thin air (#24606)
    2025-06-19 me@rreverser.com Optimise code size of addFunction. NFC (#24594)
    2025-06-18 sbc@chromium.org Fix install.py on windows (#24605)
    2025-06-18 roberthoodchatham@gmail.com JS FS: Don't return ELOOP on a path with a large number of ..'s (#24591)
    2025-06-17 sbc@chromium.org Make `wasmOffsetConvert` usage more localized in libstack_trace.js. NFC (#24599)
    2025-06-17 sbc@chromium.org Use global TLS variable in proxying.c. NFC (#24596)
    2025-06-17 sbc@chromium.org Rename _emscripten_run_on_main_thread_js. NFC (#24598)
    2025-06-17 sbc@chromium.org [test] Use do_core_test helper. NFC (#24595)
    2025-06-17 sbc@chromium.org Run npm install as part of install.py (#24568)
    2025-06-17 me@rreverser.com [embind] Use a single invoker mechanism (#24577)
    2025-06-17 sbc@chromium.org Temporarily disable asan.test_dlfcn_jspi. NFC (#24592)
    2025-06-17 sbc@chromium.org Update wasm_offset_converter. NFC (#24588)
    2025-06-17 sbc@chromium.org Fix other.test_jspi_async_function. NFC (#24590)
    2025-06-17 sbc@chromium.org Remove `Arguments` from jsdoc (#24583)
    2025-06-17 me@rreverser.com Fix Ninja support (#24584)
    2025-06-16 brendan.dahl@gmail.com [JSPI] Do not automatically wrap `async` library functions. (#24550)
    2025-06-16 sbc@chromium.org [test] Use `cflags` rather than `emcc_args`. NFC (#24578)
    2025-06-16 sbc@chromium.org [test] Add @asan decorator. NFC (#24582)
    2025-06-16 me@rreverser.com Don't use `new WebAssembly.Function` by default (#24581)
    2025-06-16 sbc@chromium.org [compiler-rt] Build with -DCOMPILER_RT_HAS_ATOMICS (#24580)
    2025-06-16 asnyder@minitab.com Add support for -fcoverage-mapping support (#24160)
    2025-06-16 jujjyl@gmail.com Fix typo in webgl_multi_draw_test.c. (#24572)
    2025-06-16 jujjyl@gmail.com Fix Firefox browser test run, and improve debugging of multiple received responses during test run. (#24573)
    2025-06-16 jujjyl@gmail.com Fix browser.test_cubegeom_row_length (#24574)
    2025-06-14 ascott.ca@gmail.com Fix `makeRemovedFSAssert()` resolved path (#24567)
    2025-06-14 jujjyl@gmail.com Optimize test_sse2 to run faster on the CI. (#24569)
    2025-06-14 sbc@chromium.org install.py: Exclude `out` directory. NFC (#24566)
    2025-06-13 sbc@chromium.org [esm-integration] Add pthread support (#24555)
    2025-06-13 jujjyl@gmail.com Optimize core*.test_avx to run faster. (#24564)
    2025-06-13 sbc@chromium.org Simplify `startWorker` pthread function. NFC (#24562)

    If this roll has caused a breakage, revert this CL and stop the roller
    using the controls here:
    https://autoroll.skia.org/r/emscripten-emscripten-releases
    Please CC dschuff@google.com,wasm-waterfall@grotations.appspotmail.com on the revert to ensure that a human
    is aware of the problem.

    To report a problem with the AutoRoller itself, please file a bug:
    https://issues.skia.org/issues/new?component=1389291&template=1850622

    Documentation for the AutoRoller is here:
    https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

    Tbr: wasm-waterfall@grotations.appspotmail.com
    Change-Id: I78d3ca71f8f2b8377073432d05a6e0a4e34ea124
    Reviewed-on: https://chromium-review.googlesource.com/c/emscripten-releases/+/6659345
    Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
    Bot-Commit: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>

I would suspect its #24577

RReverser commented

@DerThorsten Can you try reverting that PR commit in your emsdk/upstream/emscripten checkout?

hoodmane commented

Isn't -s WASM_BIGINT=1 the default? so it shouldn't be necessary to reproduce a bug?

DerThorsten commented

Isn't -s WASM_BIGINT=1 the default? so it shouldn't be necessary to reproduce a bug?

Sure, you can ommit -s WASM_BIGINT=1 since its the default.
I just wanted to point out that WASM_BIGINT beeing enabled is needed for that particular issue to appear.