DPMS change causes X to crash after recent update (fixed?)

[eccerr0r]

System: Intel i945GM graphics, x86, openrc/lightdm/xfce4

When I run x11-misc/xscreensaver-6.0.9 xscreensaver from the command line, my machine instantly kills my session and goes back to the lightdm login screen. I don't seem to get any logs, the X session just dies afaik.

I recently have USE=-wayland for all packages, wonder if there's a bad side effect with this? I don't have any other machines that I explicitly said USE=-wayland - my most similar machine (Intel HD graphics, amd64, openrc/lightdm/xfce4) works fine with default IUSE wayland settings.

I do see some EGL errors in .xsession-errors indicating perhaps there's a mesa issue with USE=-wayland but wonder if anyone ran across something like this?

Note that it's just running "xscreensaver" at the command line with no options. On a working system, the splash screen comes up, on my broken machine, I get kicked back to lightdm login.

--- Semi-Solved ---
Was able to hack libpciaccess to not crash the machine when xscreensaver and lightdm submits a DPMS request. However this does not explain why my machine is affected, just puts a bandage on the wound...

[wildhorse]

For some reason I have removed xscreensaver from all my machines a long time ago although this is the classic screensaver. Since then, I am using x11-misc/xtrlock.

I suggest you run xscreensaver with strace.

Code: Select all

strace -f -o /tmp/xscreensaver_strace.log xscreensaver

You can compare the entries between the working and broken machine. With a little bit of luck this may show you where the problem might be located. It could be anything, like an accidentally outdated shared library. Good luck.

[Hu]

A defect in xscreensaver should not be able to terminate processes other than xscreensaver, so this reads to me like xscreensaver is provoking some bug in Xorg or in the window manager. As such, I doubt strace on xscreensaver will show anything useful. I suggest using the working machine to ssh into the bad one, and attach gdb to Xorg, then continue Xorg. Do the same with your window manager. (Depending on permissions, you might need root privilege for the gdb that attaches to Xorg.) Then run xscreensaver, and check whether either gdb reports that the process terminated due to a signal, exited failure, or exited success. Once we know which process dies first, we can proceed.

[wildhorse]

A broken X11 application could kill the window manager. There is a good chance that strace shows you the screensaver's last action. That alone could be sufficient to find the cause.

It might be necessary to detach strace from any control by the calling shell. Otherwise the shell might take strace down before strace had a chance to write out its last recordings.

Code: Select all

nohup strace -f -o /tmp/xscreensaver_strace.log xscreensaver < /dev/null >& /dev/null & disown

Nothing wrong with a debugger. But strace might be sufficient.

[eccerr0r]

Haven't tried attaching gdb or strace yet but I did get diagnostic that xscreensaver got its pipe closed prematurely, so the X server stopped causing xscreensaver to die.

Sometimes I wish this wasn't my slow machine to debug... yeah it's my poor Atom...

-- EDIT --
Forgot to check this...

Code: Select all

[   717.690] (EE) Backtrace:
[   717.692] (EE) 0: /usr/bin/X (xorg_backtrace+0x5b) [0x5b98bb]
[   717.695] (EE) 1: /usr/bin/X (0x46f000+0x14ec26) [0x5bdc26]
[   717.697] (EE) 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb7fa5584]
[   717.700] (EE) 3: /usr/lib/libpciaccess.so.0 (pci_device_vgaarb_set_target+0x133) [0xb7dfc3e3]
[   717.702] (EE) 4: /usr/bin/X (0x46f000+0x18cc5c) [0x5fbc5c]
[   717.705] (EE) 5: /usr/bin/X (0x46f000+0x1692d8) [0x5d82d8]
[   717.707] (EE) 6: /usr/bin/X (0x46f000+0xdccc7) [0x54bcc7]
[   717.709] (EE) 7: /usr/bin/X (0x46f000+0xdcdd4) [0x54bdd4]
[   717.711] (EE) 8: /usr/bin/X (0x46f000+0x6bc47) [0x4dac47]
[   717.714] (EE) 9: /usr/bin/X (0x46f000+0x7023f) [0x4df23f]
[   717.716] (EE) 10: /usr/bin/X (0x46f000+0x2de7f) [0x49ce7f]
[   717.718] (EE) 11: /lib/libc.so.6 (0xb7686000+0x20dff) [0xb76a6dff]
[   717.721] (EE) 12: /lib/libc.so.6 (__libc_start_main+0x98) [0xb76a6ed8]
[   717.723] (EE) 13: /usr/bin/X (_start+0x27) [0x49ceb7]
[   717.725] (EE) 
[   717.727] (EE) Segmentation fault at address 0x1c

Now to find what the symbol table was...
---
And it crashed again on its own in lightdm I think...

Code: Select all

[  1319.385] (EE) 0: /usr/bin/X (xorg_backtrace+0x5b) [0x6388bb]
[  1319.385] (EE) 1: /usr/bin/X (0x4ee000+0x14ec26) [0x63cc26]
[  1319.385] (EE) 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb7f9d584]
[  1319.386] (EE) 3: /usr/lib/libpciaccess.so.0 (pci_device_vgaarb_set_target+0x133) [0xb7df43e3]
[  1319.386] (EE) 4: /usr/bin/X (0x4ee000+0x18cc5c) [0x67ac5c]
[  1319.387] (EE) 5: /usr/bin/X (0x4ee000+0x1692d8) [0x6572d8]
[  1319.387] (EE) 6: /usr/bin/X (0x4ee000+0xdccc7) [0x5cacc7]
[  1319.387] (EE) 7: /usr/bin/X (0x4ee000+0x147818) [0x635818]
[  1319.388] (EE) 8: /usr/bin/X (0x4ee000+0x147a15) [0x635a15]
[  1319.388] (EE) 9: /usr/bin/X (WaitForSomething+0x287) [0x635cd7]
[  1319.389] (EE) 10: /usr/bin/X (0x4ee000+0x6b9e1) [0x5599e1]
[  1319.389] (EE) 11: /usr/bin/X (0x4ee000+0x7023f) [0x55e23f]
[  1319.389] (EE) 12: /usr/bin/X (0x4ee000+0x2de7f) [0x51be7f]
[  1319.390] (EE) 13: /lib/libc.so.6 (0xb767e000+0x20dff) [0xb769edff]
[  1319.390] (EE) 14: /lib/libc.so.6 (__libc_start_main+0x98) [0xb769eed8]
[  1319.391] (EE) 15: /usr/bin/X (_start+0x27) [0x51beb7]

Ugh. time for a recompile at min to save symbol table...?

---

hmm... know what, there's another issue that is related on the amd64 machine that was also screen saver related - X would crash if the screensaver kicks in and the machine suspends or something like that, causing a hang. Wonder if there's any similarities here...

---

Call stack!

Code: Select all

(gdb) where
#0  0xb7d3c3e3 in pci_device_vgaarb_set_target ()
   from /usr/lib/libpciaccess.so.0
#1  0x00628bac in xf86VGAarbiterLock ()
#2  0x00605238 in xf86DPMS ()
#3  0x00578cb7 in DPMSSet ()
#4  0x00578dc4 in ProcDPMSDispatch ()
#5  0x00507c47 in Dispatch ()
#6  0x0050c23f in dix_main ()
#7  0x004c9e7f in main ()

[eccerr0r]

Getting somewhere!

I can crash the X server by just running

Code: Select all

$ xset -dpms

which has similarities to https://github.com/X11Libre/xserver/issues/326 ...

However

Code: Select all

$ xset +dpms
$ xset dpms 0 0

don't trigger the crash.

Also Lightdm will autocrash on the login screen if I let it sit. Fortunately with the recent xfce4 "removal" of xscreensaver embedding the screensaver never activates and after login the machine won't crash if I let it sit there.

Hmm.

[Hu]

As expected then, this is a crash in the Xorg server, which various clients can provoke by adjusting DPMS. Can you obtain file and line number debug information for the faulting function? If possible, also capture the values of locals and args at the time of the fault.

[eccerr0r]

Code: Select all

Thread 1 "X" received signal SIGSEGV, Segmentation fault.
0xb7d523e3 in pci_device_vgaarb_set_target (dev=0x0)
    at ../libpciaccess-0.18.1/src/common_vgaarb.c:235
235	        dev = pci_sys->vga_default_dev;
(gdb) print pci_sys
$1 = (struct pci_system *) 0x0
(gdb) list 235
230	    int len;
231	    char buf[BUFSIZE + 1]; /* reading BUFSIZE characters, + 1 for NULL */
232	    int ret;
233	
234	    if (!dev)
235	        dev = pci_sys->vga_default_dev;
236	    if (!dev)
237	        return -1;
238	
239	    len = snprintf(buf, BUFSIZE, "target PCI:%04x:%02x:%02x.%x",
(gdb) 

I wonder if the !dev should have been !pci_sys ?

Actually this code makes no sense as it is LOL... wtf. dev is a local, pci_sys is defined outside of this function.

--------------

I think I know what's going on and why nobody else is seeing this. I was using an inside Xorg but outside of Gentoo video driver. Perhaps this driver was partially initialized but is null because the hardware isn't installed... Seeing if I have any configs here...

Nope, after I took out that xorg.conf statement to load the driver, it wasn't that -- still crashed, back to the drawing board.

Argh. Feel like just patching it to return the -1 if pci_sys is also null. Because right now idling the laptop will cause X to crash...

[Hu]

If no dev is provided, then this function tries to default it to the value of pci_sys->vga_default_dev. The author apparently never expected that there could both not be a provided dev and not have a valid pci_sys. Treating the absence of pci_sys as having no dev seems reasonable to me, since the author clearly did try to handle the case that pci_sys is valid, but has a null vga_default_dev.

[eccerr0r]

This stopped the crashing!!!

Code: Select all

diff -ur libpciaccess-0.18.1.orig/src/common_vgaarb.c libpciaccess-0.18.1/src/common_vgaarb.c
--- libpciaccess-0.18.1.orig/src/common_vgaarb.c        2024-03-23 16:32:20.000000000 -0600
+++ libpciaccess-0.18.1/src/common_vgaarb.c     2025-07-06 16:24:04.632413386 -0
600
@@ -231,8 +231,10 @@
     char buf[BUFSIZE + 1]; /* reading BUFSIZE characters, + 1 for NULL */
     int ret;
 
-    if (!dev)
-        dev = pci_sys->vga_default_dev;
+    if (!dev) {
+        if (pci_sys) dev = pci_sys->vga_default_dev;
+       else return -1;
+    }
     if (!dev)
         return -1;
 
@@ -288,7 +290,9 @@
 {
     int len;
     char buf[BUFSIZE];
-    struct pci_device *dev = pci_sys->vga_target;
+    struct pci_device *dev;
+    if(!pci_sys) return -1;
+    dev = pci_sys->vga_target;
 
     if (!dev)
        return -1;
@@ -324,7 +328,9 @@
 {
     int len;
     char buf[BUFSIZE];
-    struct pci_device *dev = pci_sys->vga_target;
+    struct pci_device *dev;
+    if (!pci_sys) return -1;
+    dev = pci_sys->vga_target;
 
     if (!dev)
         return -1;

Whether this is kosher or not, I don't know, but I have to use this until this is fixed upstream...or something...

Before questions are asked: this machine definitely has PCI. Well, PCIe and there are devices hanging off PCIe other than the i945GM.

[eccerr0r]

The question still stands: am I the only one seeing this issue and why?

Has my eeePC dropped to second tier?

Been thinking about putting new cells into the battery pack (its battery pack is dead) but maybe not if I have a lot of one-off problems like this...

[don570]

The question still stands: am I the only one seeing this issue and why?

Has my eeePC dropped to second tier?

BarryK who develops EasyOS linux has seen this problem as well and
others on the Puppy linux forum

https://bkhome.org/news/202507/found-ca ... sario.html

He used your patch to make a Compaq Presario work with Easy OS
_____________________________________________________

[eccerr0r]

Glad it helped someone, but I'm not sure if this patch belongs in libpciaccess or not, it's quite possible that it belongs in Xorg and it should have never sent bad pointers to libpciaccess. This sort of brings back the question I had whether every level should be doing bounds checking ... and whether we are wasting CPU cycles checking at every function call, making our slow computers even slower, just to make sure people who use our software don't screw up...

That post does give one commonality: both our machines are using old intel chipset graphics (old, prior to i965), or at least I recall there was some funny business with GMA X3000 and 3100 where the X3000 is the i965 and supposedly crocus supports while the 3100 does not.

[rhem]

Hi,

I have the same problem with my laptop under Debian (an AMILO Pro V1505 with an i945GM).

I took the liberty to report it upstram at https://gitlab.freedesktop.org/xorg/lib ... /issues/25

And yes, I think there are really really few users of such computers nowadays...

best regards

[eccerr0r]

Thanks for forwarding that onto freedesktop. I don't have an account there, and worse off, not sure where the fix belongs. I suspect something to do with intel driver because I haven't seen other video adapters fail.

Seems there are more than one person affected and there may be more that just give up on this issue or have problems pinpointing it to this exact issue so there may be more than just 4 people here :)

[rhem]

I agree with you, having pci_sys set to NULL is quite suspicious for a normal execution. I just saw mesa is now pure software instead of providing hardware acceleration for OpenGL 1.x (or 2.0, I don't remember). I don't know if it can be related to the present bug or not.

I reported the bug to Debian's folks too, hoping your patch lands there... and maybe adding one or two companions in misery

[eccerr0r]

Hmm, that is possible that these old cards that don't have gallium drivers resort to software rendering. However not sure how this affects dpms.

I'm surprised and glad there are still old x86 (and pre-i965) users out there. Likely few of these support x86_64, my eeePC sure does not.

[eccerr0r]

I wonder if a bisect is needed at this point to find the true point where the bug was introduced?

Yes it seems like some code cleanup was done and forgot to initialize pci_sys ... but it's weird that only intel i915's are affected. I still haven't tried to see if other graphics are affected. Maybe try my S3...

[rhem]

Hello there,

A fix has been accepted upstream by the libpciaccess's maintainer. The fixing commit is 0b8b5f2c4632e5e0204acfd2ea892220bd8db606.

for a more detailed explanation, see https://gitlab.freedesktop.org/xorg/xse ... te_3353244

And for record, the first report of this bug was in 2014 ^_^