Bug 1138401 - [Build 20190614] openQA test fails in firefox - live medium possibly memory constrained
[Build 20190614] openQA test fails in firefox - live medium possibly memory c...
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Firefox
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Mozilla Bugs
E-mail List
https://openqa.opensuse.org/tests/961...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-06-17 07:05 UTC by Dominique Leuenberger
Modified: 2020-07-29 07:23 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dominique Leuenberger 2019-06-17 07:05:49 UTC
## Observation

openQA test in scenario opensuse-Tumbleweed-GNOME-Live-x86_64-gnome-live@uefi-usb fails in
[firefox](https://openqa.opensuse.org/tests/961222/modules/firefox/steps/10)

## Test suite description
Maintainer: okurz@suse.de, dimstar@opensuse.org

Test for openSUSE GNOME Next Live-Media


## Reproducible

Fails since (at least) Build [20190613](https://openqa.opensuse.org/tests/959093)


## Expected result

Last good: [20190612](https://openqa.opensuse.org/tests/958423) (or more recent)


## Further details

Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&machine=uefi-usb&version=Tumbleweed&flavor=GNOME-Live&test=gnome-live)


Firefox does not react (timely?) on the 'alt' key to show the menu and allow to move to the help menu. This is likely not an issue in FF directly, but rather some limitation on the LIVE CD (possibly memory constrained?)

This bug is meant as a collection pool of ideas, so that the issue can addressed fro mthe right angle
Comment 1 Oliver Kurz 2019-06-17 08:36:27 UTC
@dimstar do you think in general this issue is something that can be adressed from product side as well or only from test side?
Comment 2 Dominique Leuenberger 2019-06-17 08:51:20 UTC
(In reply to Oliver Kurz from comment #1)
> @dimstar do you think in general this issue is something that can be
> adressed from product side as well or only from test side?

If it's memory related, then the question would be why did the footprint increase - and possibly find a way to reduce it again. The live images run on 2GB of RAM after all
Comment 3 Wolfgang Rosenauer 2019-06-17 09:01:57 UTC
Default number of content processes in Firefox changed in version 66 from 4 to 8.

8 might be heavy for 2GB of RAM but should have changed many weeks ago already.
Comment 4 Oliver Kurz 2019-06-17 09:17:29 UTC
@dimstar ok, I suggest then that the people that are involved in submitting the changed components take a look into memory consumption. When we ask anyone from QA to do that while "Tumbleweed keeps rolling" they will be (steam-)rolled by Tumbleweed too soon ;)
Comment 5 Dominique Leuenberger 2019-06-17 09:20:53 UTC
(In reply to Oliver Kurz from comment #4)
> @dimstar ok, I suggest then that the people that are involved in submitting
> the changed components take a look into memory consumption. When we ask
> anyone from QA to do that while "Tumbleweed keeps rolling" they will be
> (steam-)rolled by Tumbleweed too soon ;)

which is why I filed it on boo,not poo
Comment 6 Wolfgang Rosenauer 2019-06-18 20:45:02 UTC
I do not fully understand what to do now.
Changing the default of content processes in Firefox back from 8 to 4 as a default just to pass openqa seems wrong. Changing the default back temporarily to 4 to see if it changes anything might be an option. But what if it does?
Comment 7 Oliver Kurz 2019-06-19 07:23:53 UTC
well, I doubt we have a really "openQA specific" problem. What we can do of course is change the parameters of the machine that is used for the test, e.g. give it more RAM. However I think 2GB should (still) be enough nowadays. I am not sure how that number of content processes is configured within Firefox, if this is done by upstream or in the package. However if that really makes a difference I guess setting it dynamically based on the available RAM would be nice :)
Comment 8 Wolfgang Rosenauer 2019-06-19 08:15:08 UTC
2GB for a desktop is not enough for quite some time already. Windows is even unusable with 4GB. But this just as a side note ;-)
Firefox is currently configured to 8 processes (dom.ipc.processCount) and there is no code to modify that based on number of CPUs or memory. That would be nice but is not implemented AFAICT.

// Enable multi by default.
#if !defined(MOZ_ASAN)
pref("dom.ipc.processCount", 8);
#else
pref("dom.ipc.processCount", 4);
#endif

MOZ_ASAN depends on compilation with clang which would be the default but due to SUSE's request we still build with gcc.

Anyway that being said, this can be configuration. I think we even can have an override package or something.
Like MozillaFirefox-branding-openSUSE-lowmem

But so far this discussion is based on assumptions, right? Is it possible to debug the state of such a system? Like what is using up the memory and to see if it really is memory?
Even with 8 processes after a clean startup I would not expect a massive consumption from Firefox.
Comment 10 Fabian Vogt 2019-07-10 09:07:37 UTC
The live media in openQA does not use persistence, so all changes to the filesystem are stored in RAM. This means that package installation done by openQA (there's generally no cleanup at the end) leads to ~300MiB of additional memory being used. The issues shown in the test runs don't actually appear in a 2GiB RAM VM, both firefox and oowriter work fine.

So while optimizing memory usage of firefox is a good idea in any case, this issue can likely be solved better by either not running modules which install packages in live media tests or adding a persistent overlay for all tests.

I started a test run with the former idea applied. I created a ticket for implementing the latter over a year ago: https://progress.opensuse.org/issues/34393