| Summary: | x11-misc/rss-glx with x11-misc/xscreensaver - orphaned processes | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Massimo Burcheri <burcheri.massimo+bugs-gentoo> |
| Component: | Current packages | Assignee: | Alexander Miller <alex.miller> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | boxcars, burcheri.massimo+bugs-gentoo, fabio.coatti, jstein, phmagic |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://sourceforge.net/p/rss-glx/bugs/14/ | ||
| See Also: | https://github.com/gentoo/gentoo/pull/20061 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
patch to avoid orphaned processes
rss-glx-hang.patch |
||
|
Description
Massimo Burcheri
2013-07-25 06:05:41 UTC
Please post your `emerge -vp x11-misc/rss-glx x11-misc/xscreensaver' output in a comment. $ emerge -vp x11-misc/rss-glx x11-misc/xscreensaver These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ~] x11-misc/xscreensaver-5.22 USE="jpeg opengl pam perl -gdm -new-login (-selinux) -suid -xinerama" 0 kB [ebuild R ] x11-misc/rss-glx-0.9.1 USE="bzip2 -openal -quesoglc" 0 kB Total: 2 packages (2 reinstalls), Size of downloads: 0 kB Does it help to downgrade xscreensaver to 5.21 or 5.20? Sorry for misleading. The bug was against x11-misc/xscreensaver-5.20. Meanwhile upgrading to 5.22 as seen in comment 2 solves it. Please make x11-misc/xscreensaver-5.22 stable for amd64. (In reply to Massimo Burcheri from comment #4) > Sorry for misleading. The bug was against x11-misc/xscreensaver-5.20. > Meanwhile upgrading to 5.22 as seen in comment 2 solves it. Correction. Bug is not resolved. This morning: $ pgrep -alf helios |wc -l 7 However it seems that manually activating lock with screensaver by Ctrl+Alt+Del or whatever the window manager supports does not lead to orphaned processes, but the automatically started after inactivity timeout. Is the `helios' process idling? What files does it still have open? Yes, all these processes are idle. $ pgrep -alf helios 1239 helios -r -i 300 -s 8 -e 1 -a 1 -S 1 -c 0 -b 7 -w 1258 helios -r -i 300 -s 8 -e 1 -a 1 -S 1 -c 0 -b 7 -w 1262 helios -r -i 300 -s 8 -e 1 -a 1 -S 1 -c 0 -b 7 -w 13687 helios -r -i 300 -s 8 -e 1 -a 1 -S 1 -c 0 -b 7 -w 13698 helios -r -i 300 -s 8 -e 1 -a 1 -S 1 -c 0 -b 7 -w 13721 helios -r -i 300 -s 8 -e 1 -a 1 -S 1 -c 0 -b 7 -w 13728 helios -r -i 300 -s 8 -e 1 -a 1 -S 1 -c 0 -b 7 -w $ lsof -p 1239 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME helios 1239 mo cwd DIR 254,2 4096 2 /home/mo helios 1239 mo rtd DIR 8,18 4096 2 / helios 1239 mo txt REG 8,18 148408 915072 /usr/lib64/misc/xscreensaver/helios helios 1239 mo mem REG 8,18 49744 655874 /usr/lib64/libdrm.so.2.4.0 helios 1239 mo mem REG 8,18 136152 656015 /usr/lib64/libxcb.so.1.1.0 helios 1239 mo mem REG 8,18 1296112 656041 /usr/lib64/libX11.so.6.3.0 helios 1239 mo mem REG 8,18 76040 656043 /usr/lib64/libXext.so.6.4.0 helios 1239 mo mem REG 8,18 28896 656055 /usr/lib64/libXfixes.so.3.1.0 helios 1239 mo mem REG 8,18 25088 656245 /usr/lib64/libXxf86vm.so.1.0.0 helios 1239 mo mem REG 8,18 8232 656156 /usr/lib64/libX11-xcb.so.1.0.0 helios 1239 mo mem REG 8,18 12560 656209 /usr/lib64/libXdamage.so.1.1.0 helios 1239 mo mem REG 8,18 102712 656233 /usr/lib64/libxcb-glx.so.0.0.0 helios 1239 mo mem REG 8,18 20808 656163 /usr/lib64/libxcb-dri2.so.0.0.0 helios 1239 mo mem REG 8,18 90880 914761 /lib64/libz.so.1.2.7 helios 1239 mo mem REG 8,18 37504 658487 /usr/lib64/libpciaccess.so.0.11.1 helios 1239 mo mem REG 8,18 152296 655878 /usr/lib64/libglapi.so.0.0.0 helios 1239 mo mem REG 8,18 400072 657087 /usr/lib64/opengl/xorg-x11/lib/libGL.so.1.2.0 helios 1239 mo mem REG 8,18 525928 656401 /usr/lib64/libGLU.so.1.3.1 helios 1239 mo mem REG 8,18 455432 657712 /usr/lib64/libGLEW.so.1.9.0 helios 1239 mo mem REG 8,18 58736 659191 /usr/lib64/libImplicit.so.0.0.0 helios 1239 mo mem REG 8,18 90632 654639 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.3/libgcc_s.so.1 helios 1239 mo mem REG 8,18 981664 654859 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.3/libstdc++.so.6.0.16 helios 1239 mo mem REG 8,18 29208 657669 /usr/lib64/librsMath.so.0.0.0 helios 1239 mo mem REG 8,18 146640 914096 /lib64/ld-2.15.so helios 1239 mo mem REG 8,18 1723560 914112 /lib64/libc-2.15.so helios 1239 mo mem REG 8,18 1004328 914122 /lib64/libm-2.15.so helios 1239 mo mem REG 8,18 17384 914385 /lib64/libdl-2.15.so helios 1239 mo mem REG 8,18 138200 914381 /lib64/libpthread-2.15.so helios 1239 mo mem REG 8,18 38552 914394 /lib64/librt-2.15.so helios 1239 mo mem REG 8,18 24784 654546 /usr/lib64/libXdmcp.so.6.0.0 helios 1239 mo mem REG 8,18 16624 654498 /usr/lib64/libXau.so.6.0.0 helios 1239 mo mem REG 8,18 69104 914663 /lib64/libbz2.so.1.0.6 helios 1239 mo mem REG 8,18 176456 655491 /usr/lib64/libexpat.so.1.6.0 helios 1239 mo mem CHR 226,0 57 /dev/dri/card0 helios 1239 mo mem REG 8,18 18200 392675 /usr/lib64/libtxc_dxtn.so helios 1239 mo mem REG 8,18 134976 548866 /usr/lib64/libdrm_intel.so.1.0.0 helios 1239 mo mem REG 8,18 18538040 261189 /usr/lib64/mesa/i915g_dri.so helios 1239 mo 0r CHR 1,3 0t0 5 /dev/null helios 1239 mo 1w FIFO 0,7 0t0 5069 pipe helios 1239 mo 2w FIFO 0,7 0t0 5069 pipe helios 1239 mo 3u unix 0xffff880095ea5500 0t0 694140 socket helios 1239 mo 4r FIFO 0,7 0t0 5069 pipe helios 1239 mo 5u CHR 226,0 0t0 57 /dev/dri/card0 helios 1239 mo 6u CHR 1,3 0t0 5 /dev/null helios 1239 mo 7u CHR 1,3 0t0 5 /dev/null Today I migrated Gentoo to a new machine. amd64, Core(TM) i5-3470, still Intel based graphics: 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) The issue is always the same, recently emerged x11-misc/xscreensaver-5.26 x11-misc/rss-glx-0.9.1 I made some digging in this issue; I may be mistaken, but I think that the problem is in drivers.c, signalHandler()
I see no exit(1) inside signal handler, so maybe when xscreensaver sends TERM to the process, it does not exit and the process is orphaned.
I tried this small patch:
diff -urN rss-glx_0.9.1_orig/src/driver.c rss-glx_0.9.1/src/driver.c
--- rss-glx_0.9.1_orig/src/driver.c 2015-08-31 13:15:09.032716142 +0200
+++ rss-glx_0.9.1/src/driver.c 2015-08-31 13:16:12.312679997 +0200
@@ -397,6 +397,7 @@
void signalHandler (int sig)
{
signalled = 1;
+ exit (1);
}
int main (int argc, char *argv[])
and I no longer get orphans.
I'm not sure this is the correct fix, but it seems to work. I tried to contact upstream: no feedback.
Created attachment 410976 [details, diff]
patch to avoid orphaned processes
A try to avoid orphaned process in xscreensaver.
Comment on attachment 410976 [details, diff]
patch to avoid orphaned processes
After mainLoop() is done, main() does some clean-ups. I guess it's hanging there and not in the signal handler, so I'm not sure if the exit() you introduce would give us a *clean* exit. I.e. you might be causing memory leaks this way.
Instead, debugging what happens after mainLoop() finishes might prove informative.
Thanks for the suggestion, I'll dig a bit more into this and report back Any news? This issue is still around. I was not able to reproduce that issue with geodesic and switched to that one temporarilly. I just don't like it as much as really slick helios. If http://sourceforge.net/p/rss-glx/bugs/14/ is really the same upstream issue like this I'm going to continue there. (In reply to Massimo Burcheri from comment #14) > I was not able to reproduce that issue with geodesic and switched to that > one temporarilly. I just don't like it as much as really slick helios. > > If http://sourceforge.net/p/rss-glx/bugs/14/ is really the same upstream > issue like this I'm going to continue there. It seems that geodesic is not one of rss-glx savers. I forget about this issue; I'm still using that dirty patch that I posted some time ago and found no time to debug more closely the issue. Maybe in a short while I'll try again, if only for the sake to learn a bit better about signal management :) If anyone has a better solution, please advise ;) Is anybody still able to reproduce the issue? I haven't tested the problematic use case in a long time and now all processes seem to exit cleanly. IIRC the processes used to hang somewhere in libxcb.so, but I don't remember the details. I guess it was caused by some issue in the X11 libs that has been fixed. I think this bug can be closed unless someone confirms it's still reproducible. Meanwhile I switched to more stable and simple "geodesic" screensaver. But switching back to helios I got some new orphaned processes again: 22197 helios -r -i 10 -s 10 -e 1 -a 1 -S 1 -c 1 -b 6 -w -window-id 0x9E02448 22261 helios -r -i 0 -s 30 -e 1 -a 1 -S 1 -c 1 -b 6 -w -window-id 0x9E000E1 22292 helios -r -i 0 -s 1 -e 1 -a 1 -S 1 -c 1 -b 6 -w -window-id 0x9E000E0 22438 helios -r -i 300 -s 1 -e 1 -a 1 -S 1 -c 0 -b 0 -U -w -window-id 0x9E000E1 22544 helios -r -i 300 -s 1 -e 1 -a 1 -S 1 -c 0 -b 0 -w -window-id 0x9E002D9 22602 helios -r -i 300 -s 1 -e 1 -a 1 -S 1 -c 0 -b 0 -window-id 0x9E00268 22684 helios -r -i 0 -s 1 -e 1 -a 6 -S 1 -c 0 -b 0 -w -window-id 0x9E000E1 22724 helios -r -i 0 -s 1 -e 8 -a 1 -S 1 -c 0 -b 0 -w -window-id 0x9E000E1 22826 helios -r -i 0 -s 1 -e 1 -a 1 -S 1 -c 0 -b 0 -w -window-id 0x9E005DF 22997 helios -r -i 0 -s 1 -e 0 -a 1 -S 1 -c 0 -b 0 -w -window-id 0x9E000E1 23217 helios -r -i 0 -s 1 -e 1 -a 1 -S 1 -c 0 -b 0 -U -w -window-id 0x9E00240 This was caused when testing some configurations in the xscreensaver-demo. Every configuration change leads to a frozen dialog, killing the dialog leaves orphaned processes. The xscreensaver-demo process is orphaned as well and cannot be killed -9. Created attachment 687921 [details, diff]
rss-glx-hang.patch
Thanks for reporting back, Massimo.
I'm sure these programs used to hang after receiving SIGTERM when running with --root. That issue seems to be fixed. But indeed, if running in the small preview window of xscreensaver-demo, they still hang sometimes on my system, too.
I would need to rebuild the libraries with debug info to get a more meaningful backtracke, but I can still see that helios is calling glPopMatrix() when the program hangs. The mesa GL stack ultimately calls xcb_wait_for_special_event() and that hangs in a poll() that never returns.
That means that the process hasn't exited mainLoop() yet when the graphics stack hangs. The reason is that xscreensaver-demo destroys the preview window (and creates a new one) while the hack is still running and trying to draw in that window. That's obviously a stupid idea, but on the other hand, the graphics stack shouldn't hang in such a situation but simply return an error.
There's not much we can do about it from within rss-glx. Maybe we should remove the signal handler and simply die when a signal arrives (Fabio's patch has a similar effect, but it keeps the handler). Let's try another variation first: the attached patch attempts a clean exit, but if that doesn't happen within 3 seconds the process gets killed by an alarm signal.
Could you test the patch? It works for me, but since the hangs happen in the GL stack the behaviour depends on the graphics driver.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad43009390d80e169286a6ec696b700318bdb6a2 commit ad43009390d80e169286a6ec696b700318bdb6a2 Author: Alexander Miller <alex.miller@gmx.de> AuthorDate: 2021-02-21 14:50:47 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2021-03-26 06:44:21 +0000 x11-misc/rss-glx: Workaround hanging processes Add a patch that ensures a signalled process doesn't hang indefinitely if the GL driver got stuck. Closes: https://bugs.gentoo.org/478074 Signed-off-by: Alexander Miller <alex.miller@gmx.de> Signed-off-by: Joonas Niilola <juippis@gentoo.org> x11-misc/rss-glx/files/rss-glx-0.9.1-hang.patch | 14 ++++++++++++++ .../{rss-glx-0.9.1-r2.ebuild => rss-glx-0.9.1-r3.ebuild} | 1 + 2 files changed, 15 insertions(+) |
