1687376 - Large number of idle processes (with fork server enabled?)

Status: NEW

(Core :: General, defect, P2)

Description

[Mcgiwer]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Opened a new firefox instance with a empty tab (about:blank) and looked into process manager (htop)

Actual results:

I saw that the main firefox process has opened about 150 (!!!) sub-processess, with al together "eat up" a lot of system resources (one of the sub-processes, with it's each sub-process "eat" ca. 26.4 G of virtual memory)

Expected results:

the main process should open ** only one ** sub-process for each window, tab, addon or multimedia (audio, video, flash) content

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Mcgiwer]

Component is not the gtk widget, but it's more core related. Please fix the bot's assigment of this report

Comment 3

[Andre Klapper]

Does the problem still happen if you start Firefox in Safe Mode? (Safe Mode disables add-ons, extensions and themes, hardware acceleration and some JavaScript stuff in order to exclude some possible reasons for problems.) See https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

And does this also happen with a new and empty profile? See https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile

Comment 4

[Mcgiwer]

I gdt the same issue. This seem to don't have a concrete component assigments, but it look more like a Firefox core related issue that it open so many sub-processess, with in common cause mostly that Firefox looses it's performance and can often cause a so called "freeze"

Comment 5

[Andre Klapper]

Jumping to random (and maybe wrong) conclusions ("freeze", "performance") without any references does not help.

I saw that the main firefox process has opened about 150 (!!!) sub-processess, with al together "eat up" a lot of system resources (one of the sub-processes, with it's each sub-process "eat" ca. 26.4 G of virtual memory)

If there was only 1 sub-process which took 26.4 G of memory, how would that change anything?

the main process should open ** only one ** sub-process for each window, tab, addon or multimedia (audio, video, flash) content

There is no reason to change the architecture when there is no explanation or proof that it would solve any perceived problem.

This ticket is jumping to random conclusions, so I consider this ticket neither useful nor actionable.

If you run into memory issues, then please enter the address
about:memory?verbose
in the address bar and attach (using the "Attach New File" link above) the output here.

Comment 6

[Mcgiwer]

let me try to precise it for you. In the answers I will use the short of "ff" for Firefox.

1. the main ff process has opened about 150 sub-processess (counted all together, including the sub-processess of sub-processess), in with one had the virtual size of 24.6 G, an this sub had also created sub-processess with the same size of 24.6 G

2. by the "leak of performance" and "freezr" I had meant that ff has drained the system out of resources (memory, big cpu usage), causing system lags and even that ff and system stop to response to user input. I will attempt to do screenshoot's and a dump of memory usage and add it to the report when I get able too

Comment 7

[Andre Klapper]

The actual problem that you seem to actually talk about is "high memory and cpu usage", as you seem to experience that.
The problem is not "too many sub processes" (which might be either related or not to the actual problem).

Comment 8

[Chris Peterson [:cpeterson]]

Closing this bug because it is not actionable.

Virtual memory is not a meaningful metric because it doesn't use any RAM. Look at Resident Memory instead.

"Sub-processes" in this case are process threads (or "lightweight processes"), which are cheap on Linux. We do expect to see about 150 threads when we first launch Firefox.

If you have a Firefox performance problem, please record a performance profile and open a new bug report with a link to the performance profile.

Here are instructions for using Firefox's performance profiler:

https://profiler.firefox.com/

Comment 9

[Mcgiwer]

After consulting it with the community (Question URL: https://support.mozilla.org/en-US/questions/1336801) I had decided to re-open this report.

In the mentioned above question (in given URL), I had attached a trunchated (because it was too many to fit into the screen) screenshoots showing the situation I tryed to describe.

When I had opened the about:processes tab then I had seen following output:

== Legend of used symbols ==

• The numbers in the square brackets are meaning the number of threads
• The " #X " will represent the hash (#) sign with a numeric value

== Report ==

1. Fork server [1]
2. Data Decoder [3]:

• ProfilerChild
• IPC I/O Child
• RDD Process

3. Network [variable, but while posting this report it was 8]:

• (multiple) DNS Res~ver #X
• Timer
• ProfilerChild
• IPC I/O Child
• Socket Process

4. GPU [10]

• (multiple) firefox:disk#X, where X is in (0-3)
• firefox:rcs0
• firefox:ProfilerChild
• firefox:Timer
• firefox:Compositor
• firefox:IPC I/O Child
• GPU Process

5. Web for https://mozilla.org
6. Tab - Bugzilla [variable, while posting it was 18]:

• StramTrans
• Backgro~Pool #X
• (multiple) TaskCon~read #X
• HTML5 Parser
• ProfilerChild
• ProcessHangMon
• ImageBridgeCld
• Worker Launcher
• ImageIO
• RemVidChild
• RemoteLzyStream
• Timer
• (multiple) JS Helper
• JS Watchdog
• Socket Thread
• IPC I/O Child
• IsolatedWebCo

7. Firefox [multiple, while sending it was 59]

• (multiple) FS Broker
• ProcessHangMon
• (multiple) StreamT~ns #X
• Backgro~ool #X
• (multiple) mozStorage #X
• (multiple) DOM Worker
• (multiple) TaskCon~read #X, where X is in (0-1)
• glean.dispatche
• localStorage DB
• URL Classifier
• HTML5 Parser
• Cache I/O
• gdbus
• dconf Worker
• AudioIPC Server
• AudioIPC Callba
• GMP Thread
• ImageBridgeCld
• QuotaManager IO
• gmain
• (multiple) firefox
• IPDL Background
• Image IO
• Compositor
• Softwar~cThread
• IPC Launch
• Breakpad Server
• VsyncIOThread
• Worker Launcher
• Cookie
• Cache2 I/O
• (multiple) JS Helper
• JS Watchdog
• Permission
• Socket Thread
• IPC I/O Parent

== End of report ==

Are so many threads realy needed? Most of them are working unessecary because I didn't saw them beeing called and many of them are multiple timed duplicated.

The best solution in this case would be to reduce the number of run threads to absolute minimum and make that the other threads become run on demand (request) and are closed immediatelly after this thread stop beeing needed.

Above solution would very increase the Firefox's preformance, speed and privacy

Comment 10

[Andrew McCreight [:mccr8]]

It is hard to decipher your bug report, because you are complaining about a lot of unrelated issues. Processes are not the same as threads. As Chris said, high virtual memory usage is not a problem because it does not actually use any resources on your machine. The large number of threads you report in the previous comment is completely normal.

However, the screen shot that you posted on the support page does show what looks like an unusual situation. It shows a few dozen "firefox" processes that are using no CPU. In your previous comment, you said that about:processes contained an entry that says "Fork server". Do you have the fork server enabled? We have had issues in the past with zombie processes due to the fork server.

Comment 11

[Mcgiwer]

(In reply to Andrew McCreight [:mccr8] from comment #10)

It is hard to decipher your bug report, because you are complaining about a lot of unrelated issues. Processes are not the same as threads. As Chris said, high virtual memory usage is not a problem because it does not actually use any resources on your machine. The large number of threads you report in the previous comment is completely normal.

First, Please stop changing the "component" of the bug report because it's NOT a DCOM but Performance issue (violation of the "Changing fields" rule point 1.).

Second, the issues are reaeated because they relay with one issue: Performance

To simpliffy the used by me definitions (for those who could have issues with understanding them), by sub-processess, I mean the ones with are opened from an main process, like in example:

``
main process (firefox)
|

• sub-process #1
  | |- thread #1
  | | - ...
• sub-process #2
  | |- thread #1
  | | - ...
  | +- sub-process #2-1
  | | |- thread #1
  | | | - ...
  ``

However, the screen shot that you posted on the support page does show what looks like an unusual situation. It shows a few dozen "firefox" processes that are using no CPU. In your previous comment, you said that about:processes contained an entry that says "Fork server". Do you have the fork server enabled? We have had issues in the past with zombie processes due to the fork server.

I haven't enabled it... it was automatically starting up with Firefox

Comment 12

[Gian-Carlo Pascutto [:gcp]]

I haven't enabled it... it was automatically starting up with Firefox

Can you go to about:config and look for:
dom.ipc.forkserver.enable
and tell us the value?

The screenshot you posted on the support page indeed seems to be consistent with the forkserver somehow being enabled.

First, Please stop changing the "component" of the bug report because it's NOT a DCOM but Performance issue (violation of the "Changing fields" rule point 1.).

People are changing the component because "Performance" is very generic and we want to identify which actual component is causing the unexpected behavior. DOM:Content Processes is responsible for launching additional processes to load web content. It's not 100% clear that is the root cause here, but someone who knows that module might have more info (if they were able to look at it...which is hard if the bugs keeps getting moved to the generic component).

sub-processess, I mean the ones with are opened from an main process

From your image, you mean both processes and threads. It's normal for Firefox to have a lot of threads, this is expected for optimal performance and entails minimal memory overhead for reasons already explained in this bug. We also expect a lot of processes (even more in newer versions), but your screenshot has a bunch of a type we don't expect.

Comment 13

[Mcgiwer]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #12)

Can you go to about:config and look for:
dom.ipc.forkserver.enable
and tell us the value?

It's strange, but about:config had the value set to "false"

People are changing the component because "Performance" is very generic and we want to identify which actual component is causing the unexpected behavior. DOM:Content Processes is responsible for launching additional processes to load web content. It's not 100% clear that is the root cause here, but someone who knows that module might have more info (if they were able to look at it...which is hard if the bugs keeps getting moved to the generic component).

I knot. I had set this to "Performance" (general) because I'm not sure what is the exact reason of suh behaviour. Setting ot to the given by you value seem to be inpropper because so many sub-processess and threads are opened, even when there is no real web content loaded

From your image, you mean both processes and threads. It's normal for Firefox to have a lot of threads, this is expected for optimal performance and entails minimal memory overhead for reasons already explained in this bug. We also expect a lot of processes (even more in newer versions), but your screenshot has a bunch of a type we don't expect.

I haven't compared (yet) the processess from the htop and from the about:performance, to check if there aren't any additional and unexpected processess and threads there, with aren't listed in about:performance

Comment 14

[Andrew McCreight [:mccr8]]

Maybe this is another instance of bug 1697429? There are similar symptoms.

Comment 15

[Benjamin De Kosnik [:bdekoz]]

Hey, thanks for sticking with this, we appreciate your patience. We are looking at minimizing the numbers of processes, and will continue to update this bug report.

htop/top and about:processes are diverging, many of the firefox processes are 0% CPU so maybe thresholded out of display on about:processes?

Comment 16

[Mcgiwer]

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #1)

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Nope, they seem to be two different issues, but I may be wrong

(In reply to Benjamin De Kosnik [:bdekoz] from comment #15)

htop/top and about:processes are diverging, many of the firefox processes are 0% CPU so maybe thresholded out of display on about:processes?

the about:process one was made after the htop, after the need of killing the firefox processess (and then starting it again) after it's almost made my system unresponsive

Comment 17

[Mcgiwer]

[Update: 29 July 2021]

When I aftempted to open a online game website (with was previously working without any problems), the system has suddenly slowed down and htop has showed that firefox started to use (average) 150% of cpu (I didn't even known that's possible) and when I managed to close the page, firefox had still too many sub-processess open (forked). Both almost made my computer not responsive

Comment 18

[Mcgiwer]

UPDATE [20.08.2021 21:50 (9:50 pm) CET]:

Firefox is still forking too many sub-processess, from with many seem to be clones from another and many aren't seem to be even used.

This causes that my system get an OOM (Out Of Memory) and stop to react to any user inmput (the only solution is an computer restart).

If I would compare, it's similiar reaction to an DoS attack, but it's done localy on the user's computer thru FF. I'm not sure if this shouldn't become considered as an securitu vunability.

Comment 19

[Mcgiwer]

Additional informations to the comment #18:

I had opened Firefox with a empty page (about:blank) and with turned off plugins. I list bellow the names and number of forked sub-processess (as example):

• Main process (legimate) -> forked: over 90 sub-processess
• Extensions (legimate) -> forked: 14 sub-processess
• Decoded Data (legimate) -> forked: 2 sub-processess
• Preallocated (legimate) -> forked: 12 sub-processess
• Empty website (about:blank) -> forked: 14 sub-processess

Comment 20

[Chris Peterson [:cpeterson]]

Mcgiwer, do you see the same number of processes listed in Firefox's about:processes page as in the "top" utility you used in the Mozilla Support forum post https://support.mozilla.org/en-US/questions/1336801?

Also, can you please copy and share your Firefox's about:support information in this bug?

Comment 21

[Chris Peterson [:cpeterson]]

I believe most of these "sub-processes" are threads running in the same process. For example, as far as I know, Firefox never starts more than one Extension process (shared by all extensions) or one Decoded Data process, though those processes might have multiple threads.

Comment 22

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

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 23

[Bas Schouten (:bas.schouten)]

The Performance Priority Calculator has determined this bug's performance priority to be P3. If you'd like to request re-triage, you can reset the Performance flag to "?" or needinfo the triage sheriff.

Configuration: Rare
[x] Causes severe resource usage