Closed Bug 1882301 Opened 7 months ago Closed 7 months ago

LoongArch Uint32Array Atomic compareExchange Fault

Categories

(Core :: JavaScript Engine: JIT, defect, P5)

Product:
Core
Component:
JavaScript Engine: JIT
Version:
Firefox 125
Type:
defect

Tracking

()

Status:
RESOLVED MOVED

People

(Reporter: lrzlin, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 Edg/122.0.0.0

Steps to reproduce:

open js console, input those commands and run:
const view = new Uint32Array(32);
Atomics.compareExchange(view, 8, 0, 77);
console.log(view[8]);

Actual results:

console print 0

Expected results:

which should be 77, this atomic compareExchange opreation works fine for Uint16Array

Hi Zhao, I presume this one might be for you. ;)

Blocks: 1757272
Severity: -- → S4
Flags: needinfo?(zhaojiazhong-hf)
Priority: -- → P5

Thanks for your report, but I can't reproduce this issue with mozilla-unified changeset a1e06392575f.

Could you provide more details? Which version your firefox is, and where did you get it from? Thanks!

Flags: needinfo?(zhaojiazhong-hf)

(In reply to Zhao Jiazhong from comment #2)

Thanks for your report, but I can't reproduce this issue with mozilla-unified changeset a1e06392575f.

Could you provide more details? Which version your firefox is, and where did you get it from? Thanks!

I was tested this with mozilla-unified changeset 543381939812

My test environment:

Linux 6.7.2-aosc-main
gcc (GCC) 13.2.0 20230727 (AOSC OS, Core)
ldd (GNU libc) 2.37
LLVM version 17.0.6
rustc 1.74.0

Steps to reproduce:

  1. follow the link in Building and Testing SpiderMoney and create a mozconfig file.
  2. Using ./mach build and ./mach run to build and run the js shell.
  3. Enter those commands.
const view = new Uint32Array(32);
Atomics.compareExchange(view, 8, 0, 77);
console.log(view[8]);

And I'll print 0, the expected result should be 77.
I could confirm this issue was also exist on LoongArchLinux firefox 120.0-1.
This issue may cause Firefox could not cancel download when downloading large files (500 MiB~ or larger).

(In reply to Zhao Jiazhong from comment #2)

Thanks for your report, but I can't reproduce this issue with mozilla-unified changeset a1e06392575f.

Could you provide more details? Which version your firefox is, and where did you get it from? Thanks!

Are you using Loongnix as testing system? I have tried the thunderbird 114 I compiled for Loongnix before, and this issue did disappeared.
So I guess this is probably a new-world only issue?

I'll trying build the same codebase under AOSC system and see if the issue come up again.

(In reply to Lin Runze from comment #4)

Are you using Loongnix as testing system? I have tried the thunderbird 114 I compiled for Loongnix before, and this issue did disappeared.
So I guess this is probably a new-world only issue?

Yes, I'm using Loongnix. And I can't reproduce this issue on loong64 js simulator on x64 and Firefox 120 that I built before on LoongArchLinux with gcc 13 and rust 1.76.

So I guess maybe it's related with llvm compiler, either undefined behavior in SpiderMonkey loong64 backend or bugs in llvm upstream loongarch64 port.

(In reply to Zhao Jiazhong from comment #5)

(In reply to Lin Runze from comment #4)

Are you using Loongnix as testing system? I have tried the thunderbird 114 I compiled for Loongnix before, and this issue did disappeared.
So I guess this is probably a new-world only issue?

Yes, I'm using Loongnix. And I can't reproduce this issue on loong64 js simulator on x64 and Firefox 120 that I built before on LoongArchLinux with gcc 13 and rust 1.76.

So I guess maybe it's related with llvm compiler, either undefined behavior in SpiderMonkey loong64 backend or bugs in llvm upstream loongarch64 port.

The Firefox 120 I was testing comes from the LoongArchLinux official source, so it maybe built using LLVM 16?

(In reply to Lin Runze from comment #6)

The Firefox 120 I was testing comes from the LoongArchLinux official source, so it maybe built using LLVM 16?

You can check that at about:buildconfig page of Firefox.

(In reply to Zhao Jiazhong from comment #7)

(In reply to Lin Runze from comment #6)

The Firefox 120 I was testing comes from the LoongArchLinux official source, so it maybe built using LLVM 16?

You can check that at about:buildconfig page of Firefox.

It indeed used clang 16.0.6

Built from https://hg.mozilla.org/releases/mozilla-release/rev/5ae4969c2b0450edbe68bd94b613f1f30f8a3fcb

Build platform 
target loongarch64-unknown-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
/usr/bin/clang -std=gnu99 	16.0.6 	-mabi=lp64d -march=loongarch64 -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fPIC -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe
/usr/bin/clang++ 	16.0.6 	-fno-sized-deallocation -fno-aligned-new -mabi=lp64d -march=loongarch64 -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -Wp,-D_GLIBCXX_ASSERTIONS -fno-exceptions -fPIC -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -gdwarf-4 -O2 -fomit-frame-pointer -funwind-tables
/usr/bin/rustc 	1.74.0 	

Configure options
--enable-application=browser MOZILLA_OFFICIAL=1 --enable-update-channel=release MOZBUILD_STATE_PATH=/build/firefox/src/mozbuild --disable-tests --enable-hardening --enable-alsa --enable-jack --enable-rust-simd --with-mozilla-api-keyfile=/build/firefox/src/firefox-120.0/mozilla-api-key --with-google-location-service-api-keyfile=/build/firefox/src/firefox-120.0/google-api-key --with-google-safebrowsing-api-keyfile=/build/firefox/src/firefox-120.0/google-api-key --with-unsigned-addon-scopes=app,system --allow-addon-sideload --without-wasm-sandboxed-libraries --with-system-nss --disable-updater MOZ_APP_REMOTINGNAME=firefox --enable-official-branding --prefix=/usr --with-distribution-id=org.archlinux

FWIW, I reproduced this bug on AOSC system with clang 17.0.6, but gcc 13.2.0 is good.

Since the js code is quite small and bug exists using just interpreter, so I think the bug is more likely in llvm compiler. I will try to debug it later.

This issue may cause Firefox could not cancel download when downloading large files (500 MiB~ or larger).

Seems it was a seperate issue, I'll report it as a new bug.

Specifically, there is yet another SpiderMonkey related bug: https://ruffle.rs/demo The website's content couldn't load due to an Integer Overflow, and LoongArch Chromium could load it with other any issue.

The bug in llvm loongarch64 backend is confirmed, see https://github.com/llvm/llvm-project/pull/83656. And surprisingly, there is a similar bug in GCC, not sure why it's not triggered in Firefox though.

After the fix is landed in llvm, and if the bug in Firefox is gone using new compiler, this issue could be closed then. I'm working on other issues that you mentioned, thanks!

And surprisingly, there is a similar bug in GCC, not sure why it's not triggered in Firefox though.

That's wierd... Luckily no matter what we have found a new compiler bug and fix it.

After the fix is landed in llvm, and if the bug in Firefox is gone using new compiler, this issue could be closed then. I'm working on other issues that you mentioned, thanks!

I'll also test the result as soon as the patch is landed, thanks for your hardworking!

Hi Runze,

I have tested the new llvm compiler, and this bug is gone, so I think this issue could be closed now.

Besides, the downloading cancel issue, bug 1882716, still exists with new llvm compiler, so it should be another problem.

The Integer Overflow error in ruffle demo is confirmed, it's a bug in SpiderMonkey loong64 backend, maybe you could file another issue? I will submit the fix soon.

Thank you very much!

Flags: needinfo?(lrzlin)

I have tested the new llvm compiler, and this bug is gone, so I think this issue could be closed now.

OK, I'll closed it, thanks for your work!

The Integer Overflow error in ruffle demo is confirmed, it's a bug in SpiderMonkey loong64 backend, maybe you could file another issue? I will submit the fix soon.

Then I'll open another issue for this bug.

Flags: needinfo?(lrzlin)
Status: UNCONFIRMED → RESOLVED
Closed: 7 months ago
Resolution: --- → MOVED
You need to log in before you can comment on or make changes to this bug.