firefox: PGO build failure on riscv64 rva20/rva23

[misaka00251]

Package name

firefox

openRuyi version

151.0.4

Relevant log output

Firefox 151.0.4 fails to build on riscv64 when MOZ_PGO=1 is enabled. This happens on both rva20 and rva23 build targets.

The build is configured with crashreporter disabled on riscv64:

ac_add_options --disable-crashreporter
ac_add_options MOZ_PGO=1

The Wayland compositor used for the PGO profile run appears to start successfully:

KWin is running, /home/abuild/firefox-pgo-wayland-0 is here.

However, the build fails before the actual PGO profile run, during the instrumented build link step for libxul.so:

toolkit/library/build/libxul.so
/bin/clang++ ... -fprofile-generate ... -o ../../../dist/bin/libxul.so ...
clang++: error: unable to execute command: Aborted (core dumped)
clang++: error: linker command failed due to signal

The failure happens on both rva20 & rva23.

Additional context

This issue was found while trying to enable PGO for the Firefox package on riscv64.

The current packaging already disables Firefox crashreporter on riscv64 because the C++ Breakpad crash reporter code is not yet ported to riscv64. After disabling crashreporter, the build proceeds further, but PGO still fails during the instrumented libxul.so link stage.

The current suspicion is that the riscv64 PGO instrumented build is too heavy for the current LLVM/lld setup, especially because %{optflags} still contains LTO-related flags such as:

-flto=auto
-ffat-lto-objects

The failing link line also contains -fprofile-generate, so the problematic combination may be:

riscv64 + Firefox libxul.so + PGO instrumentation + LTO/lld

I assert that this issue is relevant for openRuyi

• I assert that this is a bug and not a support request.
• I assert that this is not a duplicate of an existing issue.
• I assert that I have read the openRuyi Code of Conduct and agree to abide by it.

[misaka00251]

Here are the logs:

riscv64_rva23.txt
riscv64_rva20.txt

[sunyuechi]

Here's a similar issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1483778

[MahnoKropotkinvich]

In the bug report, someone said there's no point to enable LTO during generating PGO profile.

[misaka00251]

That person said, and I quote, "There is no point LTO'ing during the first phase of PGO. ... or maybe there is, and time will tell."

Even if we don't enable both (or PGO on riscv64), is this still an LLVM-related bug?

[MahnoKropotkinvich]

It is very likely that LTO+PGO causes very high memory pressure, at least 80GB+, leading to OOM in build environment.

[MahnoKropotkinvich]

1. I tried to build LTO+PGO profile on local SG2044 machine. It failed just like what log shows.
2. I looked around and checked dmesg -T. I saw something unusual. It said.

So I think it's very likely that LTO+PGO causes very high memory pressure, exceeding the current 85228452KB memory limit during OBS building.

3. I tried to ulimit -s unlimited and ulimit -d unlimited and triggered rebuild locally.

I forgot that the memory limit was still applied due to OBS building config so the building process failed again. But I captured the maximum memory usage using a bash script during this build and confirmed that a memory limit exceed event must have happened.

4. I chrooted into the build environment, continuing the failed linking process using ./mach build -v.

After a long time, the linking process succeeded, and the whole building process failed due to another issue unrelated to PGO. It's related to display server. On OBS I think it won't recur.

Meanwhile, the bash script detected the maximum memory usage is 88G.

To conclude, I believe it's not LLVM's bugs that would cause such build failure. Raise the memory limit to 128GB and the whole process would pass.

[sunyuechi]

Here's a similar issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1483778

Per this link, maybe we should use --enable-lto just like x86 does, and let Firefox handle internally when to enable/disable LTO, while disabling the distro-wide global LTO.

[MahnoKropotkinvich]

I looked into the osc source code and find out that the memory limit is hard-coded to 2/3 of the total memory. I uplifted total available RAM by 64GB with swap and built again, the build succeeded.