Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Updating Firefox leaves zombie process behind

NEW
Unassigned

Status

()

Toolkit
Startup and Profile System
4 years ago
10 months ago

People

(Reporter: whimboo, Unassigned)

Tracking

25 Branch
All
Linux
Points:
---

Firefox Tracking Flags

(firefox27 affected, firefox28 affected, firefox29 affected)

Details

Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20140114004002 CSet: 29c5b8def408

I noticed that already a couple of times that zombie processes of Firefox were hanging around on my Linux system. I wasn't sure yet why that happens. But today I have seen it again, and the only thing I really did after starting Firefox was to update to the latest build. So after applying the update a restart was necessary.

I have seen this behavior twice now and I'm fairly sure it is related to the application update and the replacement of files. I was able to get it reproduced the next time I tried.

Here the console ps output:
---------------------------

After starting Firefox:
$ ps -ef | grep firefox
henrik   31655  2448 70 13:03 ?        00:00:21 /mozilla/bin/aurora/firefox

After the restart to get the update applied:
$ ps -ef | grep firefox
henrik   31655  2448 75 13:03 ?        00:00:34 /mozilla/bin/aurora/firefox
henrik   31798 31655  0 13:03 ?        00:00:00 [firefox] <defunct>

This zombies stays around until I finally close Firefox.
I can also see this behavior when I upgraded Firefox 25.0b8 to 27.0b2 today. Whereby during the restart two defunct processes were visible. One of those was ended but the other stayed:

During restart:

$ ps -ef | grep firefox
henrik   32301 10958 37 13:12 pts/16   00:00:12 /mozilla/bin/beta/firefox
henrik   32417 32301  0 13:13 pts/16   00:00:00 [firefox] <defunct>
henrik   32422 32301  0 13:13 pts/16   00:00:00 [firefox] <defunct>

After restart:

henrik@whimboo:/mozilla/code/node-sonos-discovery[]$ ps -ef | grep firefox
henrik   32301 10958 42 13:12 pts/16   00:00:14 /mozilla/bin/beta/firefox
henrik   32417 32301  0 13:13 pts/16   00:00:00 [firefox] <defunct>

The problem I haven't seen when I upgraded the Firefox 24.0 release to 26.0.
status-firefox27: --- → affected
status-firefox28: --- → affected
status-firefox29: --- → affected
Henrik is the defunct process(es) causing any loss of functionality or otherwise interfering with the user experience?
Try installing a non-restartless add-on and check if there is a zombie process.
Moving to the correct component that handles the restart. Also, an answer to comment #2 and comment #3 would help.
Component: Application Update → Startup and Profile System
This isn't really a functional problem. A defunct process has properly exited but its parent has not exited or called waitpid() for it. It looks ugly in the process table but isn't consuming any real resources.

I'm a little surprised about the parent/child relationships that lead to this, but unless you want to log process starts and exits, I'm not that worried about it.

Comment 6

2 years ago
I could also see this when upgrading from 38.0.1 to 38.0.5.
Stephen, I know that we got a similar behavior fixed on OS X via the elevated updates (bug 394984). Is there anything planned for Linux too?
Flags: needinfo?(spohl.mozilla.bugs)
No, not that I'm aware of.
Flags: needinfo?(spohl.mozilla.bugs)

Comment 9

10 months ago
I can see that happening in;

Version 	52.0a1
Build ID 	20160919065232
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
OS 	Windows_NT 10.0

I'm not exactly sure how to replicate it, so I can't be sure if disabling extensions solve the issue or not. It kinda happens at random.

However I do noticed that whenever I try to run Firefox the first time after a boot, it just spawns a single process in task manager which gets stuck at 2.5~ mb ram usage and stays like that forever, until I force close and re-open it. Not sure if it has any relation to above issue.

Also trying to force close that process with either process name or pid via taskkill in Windows results in couldn't find process error. 

also updated here: https://bugzilla.mozilla.org/show_bug.cgi?id=872033
You need to log in before you can comment on or make changes to this bug.