A zombie glxtest process is left upon launching
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox112 | --- | unaffected |
firefox113 | --- | unaffected |
firefox114 | --- | fixed |
People
(Reporter: tgnff242, Assigned: stransky)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(8 files)
34.41 KB,
text/plain
|
Details | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/114.0
Steps to reproduce:
Start Firefox and watch out for zombie processes.
Actual results:
Launching Firefox creates a glxtest process which stays as a zombie until browser exit.
Expected results:
This started after Bug 1787182.
Comment 1•1 year ago
|
||
:stransky, since you are the author of the regressor, bug 1787182, could you take a look?
For more information, please visit auto_nag documentation.
Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Assignee | ||
Comment 2•1 year ago
|
||
Can you run Firefox with MOZ_GFX_DEBUG=1 env variable and attach the log here? I can't reproduce it on my box.
Thanks.
Assignee | ||
Updated•1 year ago
|
Here is the output:
GLX_TEST: childgltest start
GLX_TEST: get_pci_status start
GLX_TEST: get_pci_status finished
GLX_TEST: x11_egltest start
GLX_TEST: get_egl_status start
GLX_TEST: get_egl_gl_status start
GLX_TEST: get_egl_gl_status finished
GLX_TEST: get_egl_status finished with return: 1
GLX_TEST: get_xrandr_info start
GLX_TEST: get_xrandr_info finished
GLX_TEST: x11_egltest finished
PCI_VENDOR_ID
0x1002
PCI_DEVICE_ID
0x731f
DRI_DRIVER
radeonsi
VENDOR
AMD
RENDERER
AMD Radeon RX 5700 XT (navi10, LLVM 15.0.7, DRM 3.49, 6.2.11-arch1-1)
VERSION
4.6 (Compatibility Profile) Mesa 23.0.2
TFP
TRUE
DRM_RENDERDEVICE
/dev/dri/renderD128
MESA_VENDOR_ID
0x1002
MESA_DEVICE_ID
0x731f
DDX_DRIVER
AMD Radeon RX 5700 XT @ pci:0000:07:00.0;
TEST_TYPE
EGL
GLX_TEST: childgltest finished
vaInitialize finished
Profile: H264ConstrainedBaseline
Profile: H264Main
Profile: H264High
Profile: VP9Profile0
Profile: VP9Profile2
VAAPI_SUPPORTED
TRUE
VAAPI_HWCODECS
80
Assignee | ||
Comment 4•1 year ago
|
||
Thanks. Looks like the glxtest process run fine and we just failed to reap it. Can you attach content of about:support page?
Thanks.
Assignee | ||
Comment 6•1 year ago
|
||
I have some WIP patches ready so let's see if that fixes it. Do you also see vaapitest process hang or is that glxtest one only?
It's just glxtest; vaapitest exits properly.
Btw, to reproduce it you have to open a profile that has been used before. That is, if you create a new profile, a glxtest process will be left running only after the second time you start the browser with it.
Assignee | ||
Comment 8•1 year ago
|
||
We may also launch child processes without DONT_REAP option and use glib to get the exit status.
Assignee | ||
Comment 9•1 year ago
|
||
Assignee | ||
Comment 10•1 year ago
|
||
Depends on D175805
Assignee | ||
Comment 11•1 year ago
|
||
Depends on D175806
Assignee | ||
Comment 12•1 year ago
|
||
- Implement ManageChildProcess() to get data from child test process and process exit status. We use glib I/O routines there instead of
our custom implementation. - Update GfxInfo::GetData() and GfxInfo::GetDataVAAPI() to use it.
Depends on D175807
Assignee | ||
Comment 13•1 year ago
|
||
Depends on D175808
Assignee | ||
Comment 14•1 year ago
|
||
- Migrate glxtest pid and pipe fd variables to static members of GfxInfo on Linux
- Implement GfxInfo::FireGLXTestProcess() to run glxtest process.
Depends on D175866
Assignee | ||
Comment 15•1 year ago
|
||
- Run glxtest directly from GfxInfo::GetData() in case we're missing glx test data. That happens for unusual code paths
like profile manager run or xpcshell testing. - Remove nsIGfxInfoDebug::fireTestProcess() hack to run glxtest in testsuite. We don't need that due this change.
Depends on D175867
Comment 17•1 year ago
|
||
Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/1a8d62b0a5aa [Linux] Implement common glx/vaapi test routines in GfxInfoUtils.h r=emilio https://hg.mozilla.org/integration/autoland/rev/710a89cf3a2b [Linux] Make glxtest to use GfxInfoUtils.h routines r=emilio https://hg.mozilla.org/integration/autoland/rev/90a8a7df86c1 [Linux] Make vaapitest to use GfxInfoUtils.h routines r=emilio https://hg.mozilla.org/integration/autoland/rev/fa7593ebcb86 [Linux] Implement and use ManageChildProcess() to run and get data from child test process in GfxInfo r=emilio https://hg.mozilla.org/integration/autoland/rev/a88369c6cf8d [Linux] Implement GfxInfo::FireTestProcess() and use it to run VA-API testing r=emilio https://hg.mozilla.org/integration/autoland/rev/f9b6c77b5ae6 [Linux] Remove c style hacks to run glxtest and use FireTestProcess() for it r=emilio https://hg.mozilla.org/integration/autoland/rev/f2895f738240 [Linux] Run glxtest directly from GfxInfo::GetData() in case we're missing glx test data r=emilio
Updated•1 year ago
|
Comment 18•1 year ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/1a8d62b0a5aa
https://hg.mozilla.org/mozilla-central/rev/710a89cf3a2b
https://hg.mozilla.org/mozilla-central/rev/90a8a7df86c1
https://hg.mozilla.org/mozilla-central/rev/fa7593ebcb86
https://hg.mozilla.org/mozilla-central/rev/a88369c6cf8d
https://hg.mozilla.org/mozilla-central/rev/f9b6c77b5ae6
https://hg.mozilla.org/mozilla-central/rev/f2895f738240
Reporter | ||
Comment 20•1 year ago
|
||
The profile manager launches without a delay, but the glxtest zombie process remains. Should it be fixed on build 20230420212414?
Assignee | ||
Comment 21•1 year ago
|
||
(In reply to tgn-ff from comment #20)
The profile manager launches without a delay, but the glxtest zombie process remains. Should it be fixed on build 20230420212414?
I'll file a follow up bug to address that. I'm going to use child_watch for that.
Assignee | ||
Comment 22•1 year ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #21)
(In reply to tgn-ff from comment #20)
The profile manager launches without a delay, but the glxtest zombie process remains. Should it be fixed on build 20230420212414?
I'll file a follow up bug to address that. I'm going to use child_watch for that.
It's Bug 1829461
Description
•