Bug 729314 – www-client/firefox-77.0.1 - build does not respect parallelism and load settings and will run to completion without producing executable

• Product: Gentoo Linux
• Status: RESOLVED NEEDINFO

[Description R030t1 2020-06-23 14:55:52 UTC]

Build of recent www-client/firefox (77.0.1, but also was noticing issues with others) aborts due to invocation of OOM-killer. Either cargo or the custom build harness fails to respect MAKEOPTS. The portion of the build that uses llvm/clang does respect MAKEOPTS.

I first saw these issues being reported circa 2018 but they are still relevant.

```
# portageq envvar MAKEOPTS
-j4 -l4
```

Yet when I come back to my computer load is far over 8 (regardless of what I pass) and I must SysRq+F to regain control of the system. If left to its own devices the build either never completes in a reasonable time or has workers killed by OOM-killer without my involvement.

If I pass FEATURES="keepwork" I can resume the build however no installable executable is produced at the end despite a report of build success. This is likely more a bug of the package's build process; most GCC based packages I use will properly recover from having a worker OOM-killed. Output will be attached if I have time to reproduce but this may resolve itself if the main issue is addressed.

[Comment 1 Jan Psota 2020-06-29 06:17:59 UTC]

Same here.

[Comment 2 Thomas Deutschmann (RETIRED) 2020-06-29 11:35:28 UTC]

Cannot reproduce, working fine here.

Please show complete build.log and `emerge --info` output.

[Comment 3 R030t1 2020-06-29 14:29:22 UTC]

What did you actually try? Can you mimic memory starvation on your system? I'm not sure when I can duplicate, I just bought more RAM, but this has been an issue since 2018 and someone has verified.

Part of my intent of opening this was to use it as evidence that Mozilla should change the operation of cargo. I'm doubting this can actually be solved in Gentoo anyway.

[Comment 4 Thomas Deutschmann (RETIRED) 2020-06-29 15:36:35 UTC]

This bug is getting closed and ignored without providing requested information, sorry: That's because we have to deal with so many people mixing stuff with other repos causing problems which we cannot support.

And yes, I built firefox on real i386 which is limited to 3G.
I also run it in my chroot and I can watch how it will honor my different MAKEOPTS settings.

Also, we had some parallel make issues in the past which got fixed and confirmed by many people. At the moment it is very unlikely that you found something general broken. Maybe an edge case... but we need logs.

[Comment 5 R030t1 2020-06-29 16:08:59 UTC]

Alright, I can tell you're not paying attention. The clang/llvm part of the build abides by MAKEOPTs but the rustc/cargo portion does not. This is easily visible by watching the load average or htop. Watch the whole thing and keep an open mind instead of looking for the slightest reason to close this bug.

How many cores does your i386 have? The root cause is rustc/cargo parallelizing to the number of CPU cores, but this *seems* to not be an issue as long as you have more than 2G/core. Indeed, if I watch my system now that I have doubled the RAM, the used memory during the Firefox build never exceeds 16G (8 cores * 2G), but when I only have 16G there is not enough left for background system processes.

The only reason I am expecting some help in duplicating it is I can't constantly sit at my computer while doing nothing else waiting for Firefox to build.

Marking a bug as "resolved" and also "need info" doesn't make much sense, by the way.