First js_create_double call returns invalid value on GitHub Actions win32-x64

[jesusmb1995]

Hi Holepunch team,

We found a Windows-only issue where the first js_create_double() call in a Bare addon process can produce an invalid JS number while returning success.

This reproduces for us on GitHub Actions hosted Windows runners (windows-2022, win32-x64). We have not reproduced it on macOS/Linux, and js_create_int32() works as expected in the same minimal test.

Minimal test setup added in our PR:
tetherto/qvac@540d9a8

Minimal behavior:

t.is(addon.createDouble(2), 2, 'first js_create_double returns 2')
t.is(addon.createDouble(3), 3, 'second js_create_double returns 3')

t.is(addon.createInt32(2), 2, 'first js_create_int32 returns 2')
t.is(addon.createInt32(3), 3, 'second js_create_int32 returns 3')

Observed on win32-x64:

not ok 1 - first js_create_double returns 2
actual: 1.094924158645e-311
expected: 2

ok 2 - second js_create_double returns 3

ok 1 - first js_create_int32 returns 2
ok 2 - second js_create_int32 returns 3

Failing CI run:
https://github.com/tetherto/qvac/actions/runs/25158571461/job/73746732241

PR where we isolated and worked around the issue:
tetherto/qvac#1825

The workaround on our side is to route addon number creation through our wrapper and, on _WIN32, burn the first js_create_double() call once per process before returning the requested value. That makes CI pass, but we would prefer to remove the workaround once the underlying issue is fixed.

Relevant context:

• Platform: GitHub Actions hosted windows-2022
• Target: win32-x64
• Bare installed in CI via npm install -g bare bare-make
• Failure appears specific to the first js_create_double() call in the process
• Later js_create_double() calls and js_create_int32() calls behave correctly

Do you have any known issue around first V8 number creation / handle scope initialization on Windows, or a recommended lower-level repro we can provide?

[kasperisager]

I've recreated the issue in holepunchto/bare-addon#7, something is very fishy. I'll investigate.

[kasperisager]

This appears to be a compiler bug, upgrading from LLVM 20 to 22 fixed the issue: holepunchto/bare-addon@84f5e87