I found an 8 years old bug in Xorg

[thenbe]

Picom has an awesome feature [0] that, for the sake of all our eyes, should come by default on every device with a screen. It can continuously adjust the brightness of individual windows by averaging all the pixels in that window. It's great for defending against "flashbangs" (when a new tab burns your eyes with a blank white screen).

0: https://github.com/yshui/picom/blob/ae73f45ad9e313091cdf720d...

[kinow]

Interesting feature! Wish I had that option on my devices, combined also with something similar for sounds.

[asveikau]

> Basically when a window is created, we receive an event. After getting that event, we lock the X server, then ask it about the new window. And sometimes, the window is just not there

Relying on this sounds like a race condition even if the lock is working. In the time between you process the event and getting the lock, the window could have been destroyed.

[marmight]

I don't know if it is sufficient to prevent the race, but the article does mention that they check for DestroyNotify events after the grab.

[Jasper_]

The immediate destruction of client resources even under server grab is not new functionality to the epoll port; it behaved the same under the old select-based loop, too. It might be a bug, but that's how it's always behaved.

It shouldn't be too hard to fix if you want to try, either; check client->ignoreCount > 0 when handling X_NOTIFY_ERROR before calling CloseDownClient.

[wavemode]

By Xorg standards, "8 years old" is basically brand new.

[yjftsjthsd-h]

Yeah, my honest reaction to the title was something like: that's a surprisingly young bug for that code base; I'm used to seeing headlines about finding X bugs that have been in there for literally decades.

[jraph]

> I could attach a debugger to the X server, however, debugging the X server pauses it, which would be a problem if I was debugging from inside that X session. Beside that, window destruction happens quite often, which can be prohibitive for manual debugging. It's still possible with a remote ssh connection, and gdb scripting, but it's inconvenient.

I will definitely look into eBPF and uprobe mentioned in the article, I don't know about them. But wouldn't something like XNest (or XWayland?) help with debugging X? You'd debug an X server running in a window comfortably from your real environment and display server without it being disrupted by the debugging session.

[TillE]

> It's still possible with a remote ssh connection, and gdb scripting, but it's inconvenient.

In this situation, don't gdb breakpoint command lists give you exactly what you need (printing stack traces at certain points) with minimal effort? Nothing wrong with using different tools, but it's not clear if that option was considered.

[gpvos]

So, how has this been resolved? Has the bug been fixed now?

[srigi]

See for yourself:

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1691

[hulitu]

> To put it simply, picom needs to fetch the window tree from X. But there is no way to get the whole tree in one go

There are a lot of WMs who offer a window list (twm, fvwm). Maybe the guy shall take a look how they do it.

And requests to the X server are not syncroneus.

[MadnessASAP]

As they mention, the Window Manager, being the authority on which windows are displayed would obviously have that information. Picoms issue is that it is seperate from the WM and does not have access to that, it needs to go through the X server to discover the windows.

[jeffbee]

There are undoubtedly flaws in Xorg dating to this and each of the previous four decades.

[proneb1rd]

Planning on fixing this bug? :-)

[nairboon]

Interesting article, although it could use some more hyperlinks, e.g. to the bug.

[przemub]

In Xorg timescales that's probably one of the youngest bugs :D

[firesteelrain]

I don’t understand why mention he was using .NET with Wine if not going to tell us why. Just silly

EDIT: Downvote but don't respond. Even sillier!