1666051 - Test cases (was: Crash at weird memory address on 32-bit builds)

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: debug stack

+++ This bug was initially created as a clone of Bug #1664953 +++

(function (stdlib) {
  "use asm";
  var sqrt = stdlib.Math.sqrt;
  function f(i0) {
    i0 = i0 | 0;
    i0 = ~~sqrt(-.5);
    return (1 / (1 >> (.0 == .0)) & i0 >> 1);
  }
  return f;
})(this)();

Opt shell:

(gdb) bt
#0  0x3d3bf004 in ?? ()
#1  0x7ff00000 in ?? ()
#2  0x3d3af114 in ?? ()
#3  0xf66f64c0 in ?? ()
(gdb) x/i $pc
=> 0x3d3bf004:	mov    0x10(%esi),%ecx
(gdb) x/b $esi
0x7ff00000:	Cannot access memory at address 0x7ff00000
(gdb) x/b $ecx
0xffffaad8:	0x00
(gdb)

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/09390cf1d667
user:        Dmitry Bezhetskov
date:        Mon Sep 14 05:19:44 2020 +0000
summary:     Bug 1639153 - Part 6.6: Add tls dependency for truncate i32. r=lth

Run with --fuzzing-safe --no-threads --no-baseline --no-ion, compile with AR=ar sh ./configure --host=x86_64-pc-linux-gnu --target=i686-pc-linux --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests, tested on m-c rev ab7d302fd318.

This seems specific to 32-bit builds.

Comment 1

[Lars T Hansen [:lth]]

Likely a dup of <redacted>, will check after the patch for that lands.

Comment 2

[Dmitry Bezhetskov]

Attachment: Bug 1666051 - Fix WasmTls cloberring before preserving. r=lth

Comment 3

[Dmitry Bezhetskov]

Actually this is the new bug, on x86 we assign WasmTlsReg as a return register for WasmBuiltinTruncateDToInt32 and clobber it in masm.branchTruncateDoubleMaybeModUint32 and then preserve/restore it on the ool path.

Comment 4

[Lars T Hansen [:lth]]

Patch tentatively OK, needs commit message + try run. Will approve, but do not land anything without a green try run.

Comment 5

[Daniel Veditz [:dveditz] back 2026-04-08]

sec-high assuming "return register" is a jump location and not the return value.

Comment 6

[Lars T Hansen [:lth]]

I think this was fixed by a recent mega-backout, will retest.

Comment 7

[Lars T Hansen [:lth]]

I can repro on the named rev but not on current m-c, and I will assume the backout of bug 1639153 fixed this.

Comment 8

[Ryan VanderMeulen (PTO, back 6-April)]

Should we land the testcase from this bug?

Comment 9

[Lars T Hansen [:lth]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #8)

Should we land the testcase from this bug?

Yeah, we should. I'll prepare a patch.

Comment 10

[Lars T Hansen [:lth]]

Landing test cases is not P1.

Comment 11

[Lars T Hansen [:lth]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a351d72bdb50e007e342ec4ef1f7aed643f98ae9 (not security sensitive, as problems were backed out everywhere last week).

Comment 12

[Lars T Hansen [:lth]]

Attachment: Bug 1666051 - Sundry fuzztest cases for backed-out ABI changes. r?rhunt

Comment 13

[Lars T Hansen [:lth]]

Test cases can just land, the offending code was backed out.

Comment 14

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/ff4f8778145df6c42e137ee8be10afc495e0069e
https://hg.mozilla.org/mozilla-central/rev/ff4f8778145d

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.

Please visit this google form to reply.