#672250 rss-glx: pixelcity/helios/drempels/lorenz/fieldlines keep running in the background, eating up the cpu

Package:
rss-glx
Source:
rss-glx
Description:
Really Slick Screensavers GLX Port
Submitter:
Christian Michallek
Date:
2026-09-02 15:03:01 UTC
Severity:
important
#672250#5
Date:
2012-05-09 13:18:33 UTC
From:
To:
Dear Maintainer,

i've noticed, that some screensaver from this package wont stop.
the process keeps running in the background.
Cant reproduce it, when i execute them manually.
im using XFCE and xscreensaver.

greetings

christian
#672250#10
Date:
2012-05-23 08:43:15 UTC
From:
To:
Hello,

I have the same problem on two computers here, and for what I saw, I
think all the xscreensaver hacks from this package are affected.

I am not sure of what causes it, but here are the symptoms:
1. xscreensaver is activated;
2. it starts a hack from rss-glx;
3. the hack runs for a while;
4. xscreensaver changes to another hack, or deactivates;
5. the hack from rss-glx continues to run (doing what exactly?), eating
    one 100% of one CPU, does not answers to SIGTERMs and has to be
    SIGKILLed.

When a hack from this package is launched by hand from outside of
xscreensaver, I can see nothing abnormal: it stops when its window is
destroyed, or when it is SIGTERMed.

Good luck,
#672250#17
Date:
2024-01-27 15:42:36 UTC
From:
To:
Would it be possible for someone that can reproduce this bug to do the following:

 * Install the rss-glx-dbgsym package
 * Provoke the bug
 * Attach gdb to the running process with 'gdb --pid <process ID>'
 * Grab a backtrace and upload here?

If I can see where the process is stuck I'm willing to take a quick look to see if it can be easily fixed.

Thanks!
#672250#22
Date:
2024-08-29 23:31:53 UTC
From:
To:
I started sundancer2 within xscreensaver-demo and then clicked on
another screensaver, causing xscreensaver-demo to hang.

When started manually on the cli, the screensaver stops and exits
properly.

Attaching to process 316961
[New LWP 316963]
[New LWP 316962]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f76cdfbbb5f in __GI___poll (fds=0x7ffec5852e38, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29

warning: 29	../sysdeps/unix/sysv/linux/poll.c: No such file or directory
(gdb) bt
#0  0x00007f76cdfbbb5f in __GI___poll (fds=0x7ffec5852e38, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f76cddb4d82 in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007f76cddb7242 in xcb_wait_for_special_event () from /lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007f76cdd4fff8 in glLabelObjectEXT () from /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#4  0x00007f76cdd501c8 in glLabelObjectEXT () from /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#5  0x00007f76cdd52a61 in glLabelObjectEXT () from /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#6  0x00007f76cdd52d6d in glLabelObjectEXT () from /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#7  0x00007f76cb4b9f85 in ?? () from /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so
#8  0x00007f76cb4ba02e in ?? () from /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so
#9  0x00007f76cb4bd1e4 in ?? () from /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so
#10 0x00007f76cb58abcf in ?? () from /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so
#11 0x00007f76cb58bab5 in ?? () from /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so
#12 0x00007f76cb7f90c7 in ?? () from /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so
#13 0x00007f76cb7fdb7d in ?? () from /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so
#14 0x0000564b297acabe in hack_draw (XStuff=<optimized out>, currentTime=1724973929.092783, frameTime=<optimized out>)
    at ./src/sundancer2.c:176
#15 0x0000564b297ac0e3 in mainLoop () at ./src/driver.c:240
#16 0x0000564b297ab627 in main (argc=4, argv=0x7ffec58538f8) at ./src/driver.c:463
(gdb)
#672250#27
Date:
2025-10-27 13:15:47 UTC
From:
To:
I had the opportunity to test this again, this time on slightly different
hardware. Here the problem cannot be reproduced in 100% of cases, sometimes
the screensaver exits as intended.

Same scenario as before. Terminal output when the screensaver is started:

----->8
sundancer2: unrecognized option '--window-id'
----->8

When I try to switch to a different one but it hangs, no additional output
is generated. In some cases switching away from it works, but the following
is printed to the Terminal:

  Minor opcode of failed request:  1
  Resource id in failed request:  0x2c0073d
  Serial number of failed request:  169
  Current serial number in output stream:  171
----->8

So I speculate the difference between the case where the screensaver is run
from within xscreensaver and often hangs when it should quit, while it
successfully exits every time when run on its own, is due to xscreensaver
"stopping" the screensaver by destroying its window, and the screensaver
not coping well depending on when this happens.

Current backtrace:

Attaching to process 149972
[New LWP 149974]
[New LWP 149973]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__syscall_cancel_arch () at
../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56

warning: 56 ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S: No such
file or directory
(gdb) bt
#0  __syscall_cancel_arch () at
../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
#1  0x00007f21c8e4d668 in __internal_syscall_cancel (a1=<optimized out>,
a2=<optimized out>, a3=<optimized out>, a4=a4@entry=0, a5=a5@entry=0,
a6=a6@entry=0,
    nr=7) at ./nptl/cancellation.c:49
#2  0x00007f21c8e4d6ad in __syscall_cancel (a1=<optimized out>,
a2=<optimized out>, a3=<optimized out>, a4=a4@entry=0, a5=a5@entry=0,
a6=a6@entry=0, nr=7)
    at ./nptl/cancellation.c:75
#3  0x00007f21c8ec19c6 in __GI___poll (fds=<optimized out>, nfds=<optimized
out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:29
#4  0x00007f21c8cb0d82 in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1
#5  0x00007f21c8cb2f12 in xcb_wait_for_special_event () from
/lib/x86_64-linux-gnu/libxcb.so.1
#6  0x00007f21c5efad47 in ?? () from /lib/x86_64-linux-gnu/
libgallium-25.2.5-1.so
#7  0x00007f21c5efaefd in ?? () from /lib/x86_64-linux-gnu/
libgallium-25.2.5-1.so
#8  0x00007f21c5efdbe1 in ?? () from /lib/x86_64-linux-gnu/
libgallium-25.2.5-1.so
#9  0x00007f21c5efdf98 in loader_dri3_get_buffers () from
/lib/x86_64-linux-gnu/libgallium-25.2.5-1.so
#10 0x00007f21c5eff8a4 in ?? () from /lib/x86_64-linux-gnu/
libgallium-25.2.5-1.so
#11 0x00007f21c5eff939 in ?? () from /lib/x86_64-linux-gnu/
libgallium-25.2.5-1.so
#12 0x00007f21c5ef6e44 in ?? () from /lib/x86_64-linux-gnu/
libgallium-25.2.5-1.so
#13 0x00007f21c5fa2aea in ?? () from /lib/x86_64-linux-gnu/
libgallium-25.2.5-1.so
#14 0x00007f21c5fa39b7 in ?? () from /lib/x86_64-linux-gnu/
libgallium-25.2.5-1.so
#15 0x00007f21c621b1f9 in ?? () from /lib/x86_64-linux-gnu/
libgallium-25.2.5-1.so
#16 0x00007f21c6220acf in ?? () from /lib/x86_64-linux-gnu/
libgallium-25.2.5-1.so
#17 0x0000559db4d57b2e in hack_draw (XStuff=<optimized out>,
currentTime=1761566877.2812519, frameTime=<optimized out>) at
./src/sundancer2.c:176
#18 0x0000559db4d570e6 in mainLoop () at ./src/driver.c:240
#19 0x0000559db4d56626 in main (argc=4, argv=0x7fff3e5c70f8) at
./src/driver.c:463
#672250#32
Date:
2026-09-02 15:01:30 UTC
From:
To:
Hello,

I can reproduce a related rss-glx termination problem with rss-glx
0.9.1-7 and XScreenSaver on Debian 13 (Trixie).

A note on the origin of this report: the investigation, diagnosis, and
proposed patch were worked out interactively with ChatGPT. I performed
the commands and tests on my actual Debian 13 system and verified the
results described below, but I do not want to present the technical
analysis as entirely my own work.

In XScreenSaver, when changing the settings of the "lattice" screensaver
and pressing OK, the settings are written successfully to
~/.xscreensaver, but the settings dialog hangs while waiting for the
lattice preview process to terminate.

While it is hanging:

```
pkill -TERM -x lattice
```

has no effect, whereas:

```
pkill -KILL -x lattice
```

immediately terminates lattice and releases the XScreenSaver dialog.

During the investigation, ChatGPT pointed out that src/driver.c installs
the common signal handler for SIGTERM:

```
sa.sa_handler = signalHandler;
sigaction (SIGINT, &sa, 0);
sigaction (SIGPIPE, &sa, 0);
sigaction (SIGQUIT, &sa, 0);
sigaction (SIGTERM, &sa, 0);
```

The signal handler only sets "signalled = 1". The hypothesis was that,
if the program is blocked inside the rendering/GL code, it may not
return to the point where that flag is acted upon.

To test this, I removed only this line:

```
sigaction (SIGTERM, &sa, 0);
```

and rebuilt rss-glx 0.9.1-7 locally on Debian 13.

I installed the resulting locally versioned package:

```
rss-glx 0.9.1-7+termfix1
```

With this change, XScreenSaver can terminate lattice normally and its
settings dialog no longer hangs.

I also tested the settings dialogs of the other installed rss-glx
screensavers. They continue to work normally and I observed no freezes
or other regressions.

So, based on this test, leaving SIGTERM at its default disposition
appears to fix at least this class of rss-glx termination hangs.

Again, the technical diagnosis and suggested source-code change came out
of an interactive troubleshooting session with ChatGPT; my contribution
here was reproducing the problem, running the tests, rebuilding the
package, and confirming that the modification fixes the issue on my system.

Regards
Frank