Latest 32-bit build crashes on this forum on hcaptcha.com

[UCyborg]

I get this on multiple machines with fresh profile - try logging onto this forum a few times with wrong password so it'll display captcha. Afterwards, the browser crashes in xul.dll. The issue doesn't affect 64-bit build. I also tested with disabled hardware acceleration, just in case, but it doesn't matter.

[Moonchild]

viewtopic.php?f=3&t=49 please.
Kindly include an appcrashview report and/or generate a minidump

[UCyborg]

Didn't think it'd be necessary since it appears easily reproducible.

Minidump

[moonbat]

Didn't think it'd be necessary since it appears easily reproducible.

A crash dump from your system would show better what's going on, since this is a crash and not a simple case of a broken website or similar.

[Moonchild]

As far as I can tell from the minidump it's a problem with the WASM compiler hcaptcha uses (probably for an automated browser check) causing an incorrect stack.
potentially it hasn't been tested well with 32-bit browsers with WASM?
As a workaround you could disable WASM in the browser, it'll force hCaptcha to fall back to normal javascript. in about:config, set javascript.options.wasm to false to disable.

[UCyborg]

Interesting, so given the nature of the issue it happens Pale Moon as well if you turn on both WASM options. I figured I can keep WASM support and just disable javascript.options.wasm_baselinejit, then it doesn't crash neither, if that gives any extra clues.

[UCyborg]

No issues on 32-bit Firefox 78. It has some extra WASM options in about:config. I tried disabling the extra ones, hcaptcha.com still worked without crashing.

[Moonchild]

Yeah it's a problem with the baseline jit compiler for WASM in our platform. It doesn't like being fed native 64-bit WASM code that has things cast to 64-bit; the crash occurs because it fails a type check, and hits a deliberate breakpoint rather than silently failing and leaving a potential safety hazard due to type confusion.
The option to simply disable baselinejit on 32-bit is a good short-term workaround. I'm not entirely sure if it's feasible to fix the baseline jit compiler for WASM for 32-bit because it was designed for x64 primarily, and x86 support was kind of an afterthought by Mozilla. After our fork point things in that area were refactored and I don't think we have anyone in our team with enough specialized knowledge to do something similar to fix x86 handling of native x64 WASM code.

[drazen]

Hi all,

I'm the lead dev over at hcatpcha wasm side, thanks for raising this issue.

The cause was indeed an i64 cast we're doing deep down when working with timestamps. We've implemented a workaround for the cast, we've tested it with `2020.06.10 (32-bit)` version and wasm works as expected. The patch should be live later today.

We strive to be as compatible as possible, thanks once again for raising this

[Moonchild]

Hi drazen,

Thanks for taking the time to come in and add to this thread with a confirmation of the problem and a deployment of the fix for 32-bit Basilisk; I've raised Issue #1605 (UXP) on our issue tracker for this but considering it seems the only web compatibility there is was in hCaptcha so far and a fix is in the pipeline, we might take a less aggressive approach and retain our performance boost for WASM for 32-bit by default.

I appreciate the involvement of fellow devs with our projects and the kind of pleasant conversation I've had with you folks around this issue. Thanks!