#14 Rss-glx (x)screensaver hacks won't die when returning to desktop

[B. Kaatz]

Greetings,

I have seen this cropping up more and more lately.

Behavior:
When running xscreensaver with rss-glx added, occasionally an rss-glx hack will peg a core at 100% and then get "stuck". Xscreensaver will even move to another screensaver hack (when set on "Random"), leaving the stuck hack still running at 100% CPU but not displaying to the screen. Returning to the desktop leaves the stuck hack running.

From running 'top' in lxterm on the desktop:

Tasks: 254 total,   2 running, 252 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.8 us, 16.6 sy,  8.7 ni, 72.5 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   8160604 total,  8009636 used,   150968 free,   605548 buffers
KiB Swap:  7653372 total,     4720 used,  7648652 free.  3615260 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
25768 bkaatz    30  10   91736  33420  20196 R 100.0  0.4 898:32.37 feedback    
 7845 bkaatz    20   0 1026372 221456  58748 S   5.3  2.7 264:51.81 chrome      
25257 bkaatz    20   0 3592904 225324  13504 S   1.0  2.8   0:10.73 java        

When this happens, a 'kill' command won't work without the following conditions:
1.) You must use 'kill -9' to kill the runaway hack. Using 'kill -15' will not stop the running hack.
2.) The 'kill' command must come from the account that the hack was launched under. Even root will not stop it with a 'kill -9'.

I am running Gentoo linux, and have attached my 'emerge --info' to this ticket, but the Reader's Digest version is this; I have an Intel Core2 Quad Q6700 with an Nvidia GeForce 9500 GT and I am running kernel version 3.10.25 with the proprietary Nvidia drivers version 340.24.

Looking through the logs, I didn't see anything relating to it from /var/log/Xorg.0.log, but I saw these snippets from /var/log/messages:

Aug  7 18:20:01 tech8 cron[24730]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Aug  7 18:30:01 tech8 cron[25071]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Aug  7 18:30:04 tech8 kernel: NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ChID 0005, Class 00008297, Offset 00001640, Data bea68a8f
Aug  7 18:40:01 tech8 cron[25429]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Aug  7 18:50:01 tech8 cron[25752]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Aug  7 18:59:01 tech8 cron[26083]: (root) CMD (rm -f /var/spool/cron/lastrun/cron.hourly)
Aug  7 19:00:01 tech8 cron[26108]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Aug  7 19:00:09 tech8 kernel: NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ChID 0005, Class 00008297, Offset 000015e0, Data 00000000
Aug  7 19:10:01 tech8 cron[26460]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Aug  7 19:20:01 tech8 cron[26778]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)

...<snip>...

Aug  8 00:40:01 tech8 cron[5384]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Aug  8 00:50:01 tech8 cron[5756]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Aug  8 00:50:15 tech8 kernel: skyrocket[5772]: segfault at 56105f ip 0000000000412768 sp 00007fffd140cc90 error 4 in skyrocket[400000+160000]
Aug  8 00:59:01 tech8 cron[6007]: (root) CMD (rm -f /var/spool/cron/lastrun/cron.hourly)
Aug  8 01:00:01 tech8 cron[6055]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)

...<snip>...

Aug  8 10:00:01 tech8 cron[25293]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Aug  8 10:01:50 tech8 kernel: NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ChID 0005, Class 0000502d, Offset 00000104, Data 00000001
Aug  8 10:10:01 tech8 cron[25352]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Aug  8 10:20:01 tech8 cron[25381]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)

The last NVRM entry at 10:01:50 was when I killed the runaway 'feedback' hack.

I have directly seen this behavior with 'feedback', 'pixelcity', 'cyclone' and 'hufo_smoke'. I'm not sure that the segfault with 'skyrocket' has anything to do with this, but since it was in the logfile, I included it here, just in case.

If you need any more information, just let me know.

TIA for your time and attention to this.

[B. Kaatz]

I apologize.

I forgot to include the following information:
x11-misc/rss-glx: 0.9.1
x11-misc/xscreensaver: 5.26

HTH.

[Lectrode]

I know this is old, but I can still reproduce this running just the individual screensavers. Not even using Xscreensaver, just running the screensaver directly. Interestingly enough, the issue is only prevalent when you run the screensaver with --root argument (which is how Xscreensaver runs it).

I've produced this on both Xubuntu 14.04 (Ubuntu, Xfce) and Manjaro 15.12 (Arch, Xfce). I'm only including the results from Manjaro as that is the more current system (from just this past month with latest updates).

System Info:

rss-glx 0.9.1-23

(I'm using bumblebee to switch between descrete and main graphics card. This issue exists no matter which one I use, and with either Open or Proprietary drivers)

$ uname -r
4.1.15-1-MANJARO

$ lspci | grep -E "VGA|3D"
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K1100M] (rev a1)

Here's a gdb backtrace from running "lattice --root"

$ gdb --args lattice --root
GNU gdb (GDB) 7.10.1
Reading symbols from lattice...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/lattice --root
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
^C
Program received signal SIGINT, Interrupt.
0x00007ffff66fd170 in __poll_nocancel () from /usr/lib/libc.so.6
(gdb) backtrace
#0  0x00007ffff66fd170 in __poll_nocancel () from /usr/lib/libc.so.6
#1  0x00007ffff3fb6ae2 in ?? () from /usr/lib/libxcb.so.1
#2  0x00007ffff3fb8829 in xcb_wait_for_special_event () from /usr/lib/libxcb.so.1
#3  0x00007ffff726b787 in ?? () from /usr/lib/libGL.so.1
#4  0x00007ffff726c530 in ?? () from /usr/lib/libGL.so.1
#5  0x00007ffff28b00db in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
This GDB was configured as "x86_64-unknown-linux-gnu".
#6  0x00007ffff28b0431 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#7  0x00007ffff28a2340 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#8  0x00000000004054aa in ?? ()
#9  0x0000000000402f26 in ?? ()
#10 0x00000000004023fa in ?? ()
#11 0x00007ffff663d610 in __libc_start_main () from /usr/lib/libc.so.6
#12 0x00000000004024f9 in ?? ()
(gdb) q
A debugging session is active.

    Inferior 1 [process 22665] will be killed.

Quit anyway? (y or n) y

It runs fine until you try to end it. Obviously, "^C" is when I sent the end signal, however it doesn't end. Hence the issue.

[Massimo B.]

I can reproduce that for a long time now with my favourite screensaver helios:
https://bugs.gentoo.org/show_bug.cgi?id=478074
Just every time the screensaver starts it leaves processes behind consuming CPU:

# pgrep -alf helios
7337 helios -r -i 10 -s 10 -e 1 -a 1 -S 1 -c 1 -b 6 -w
7338 helios -r -i 10 -s 10 -e 1 -a 1 -S 1 -c 1 -b 6 -w
7339 helios -r -i 10 -s 10 -e 1 -a 1 -S 1 -c 1 -b 6 -w

While kill doesn't work I almost always need to do

killall -9 helios

after leaving screensaver.

[Massimo B.]

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 the really slick helios.
P.S.: Ok, that geodesic code is part of xscreensaver package, not the rss-glx.