Last Comment Bug 677531 - GLXtest process stays around as zombie until the data is used by GfxInfo
: GLXtest process stays around as zombie until the data is used by GfxInfo
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: unspecified
: All Linux
: -- normal (vote)
: mozilla9
Assigned To: Nobody; OK to take it and work on it
: Milan Sreckovic [:milan]
Depends on:
Blocks: 697963
  Show dependency treegraph
Reported: 2011-08-09 07:14 PDT by Benoit Jacob [:bjacob] (mostly away)
Modified: 2011-11-04 05:55 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

always call GetFeatureStatus to cause GfxInfo initialization, as that's what kills the zombie (1.86 KB, patch)
2011-08-17 15:45 PDT, Benoit Jacob [:bjacob] (mostly away)
matt.woodrow: review+
Details | Diff | Splinter Review

Description Benoit Jacob [:bjacob] (mostly away) 2011-08-09 07:14:10 PDT
As long as the data is never used, because WebGL and other graphics features are not used, the GLXtest process stays around as a zombie.

We already take good care of freeing its resources so that this zombie uses minimal memory, but it would be nice to not have it at all.

That would be fixed if we did the read-data-and-call-waitpid() in Firefox in a place that's always run on startup. Soon, we will turn on accelerated layers by default on X11 so we will always do that in the default configuration, but not if people explicitly disable layers acceleration.
Comment 1 Ted Mielczarek [:ted.mielczarek] 2011-08-11 04:34:55 PDT
Does this process persist beyond a Firefox restart? (An in-browser restart to apply updates.) I think it might, because I just noticed this on my Ubuntu machine:
luser@cuatro:~$ ps -ef | grep firefox
luser     1616  2617  0 Aug08 ?        00:00:00 [firefox] <defunct>
luser     1978  2617  0 Aug04 ?        00:00:00 [firefox] <defunct>
luser     2617     1  1 Jul30 ?        03:23:01 /home/luser/firefox/firefox
luser     7880  2617  0 Aug09 ?        00:00:00 [firefox] <defunct>
luser     7882  2617  0 Aug09 ?        00:00:00 [firefox] <defunct>
luser     8152  2617  0 Aug09 ?        00:00:00 [firefox] <defunct>
luser    11719  2617  0 Jul31 ?        00:00:00 [firefox] <defunct>
luser    12144  2617  0 Aug03 ?        00:00:00 [firefox] <defunct>
luser    15627  2617  0 Aug01 ?        00:00:00 [firefox] <defunct>
luser    22755  2617  0 Aug06 ?        00:00:00 [firefox] <defunct>
luser    23920  2617  0 Aug05 ?        00:00:00 [firefox] <defunct>
luser    26617  2617  0 Aug02 ?        00:00:00 [firefox] <defunct>
luser    27467 27391  0 07:34 pts/3    00:00:00 grep firefox
luser    29913  2617  0 Aug07 ?        00:00:00 [firefox] <defunct>
luser    29915  2617  0 Aug07 ?        00:00:00 [firefox] <defunct>
Comment 2 Benoit Jacob [:bjacob] (mostly away) 2011-08-17 15:04:59 PDT
Yes, this is expected, but good point, it does make the problem look worse.
Comment 3 Benoit Jacob [:bjacob] (mostly away) 2011-08-17 15:45:48 PDT
Created attachment 553935 [details] [diff] [review]
always call GetFeatureStatus to cause GfxInfo initialization, as that's what kills the zombie

This patch makes us call GetFeatureStatus BEFORE the early return paths, so it's always called.

The downside is doing some useless work when the GfxInfo information is not needed, but that's not meant to ever happen in default configs (the normal behavior in default config is to check GfxInfo and use that information to decide whether to use layers acceleration).
Comment 4 Benoit Jacob [:bjacob] (mostly away) 2011-08-17 15:46:52 PDT
Also, AFAIU zombie processes could only stay around in non-default configs where acceleration was either disabled or force-enabled; or in safe mode.
Comment 5 Benoit Jacob [:bjacob] (mostly away) 2011-08-19 08:43:06 PDT
Comment 6 :aceman 2011-11-04 01:59:27 PDT
Could you please mark Target Milestone in which this was solved so we can check if bug 697963 is the same?
Comment 7 Benoit Jacob [:bjacob] (mostly away) 2011-11-04 05:55:30 PDT
There has been at least 1 other bug fixed  (bug 681026) and I think the target milestone is 9.

Note You need to log in before you can comment on or make changes to this bug.