I found an 8 years old bug in Xorg

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&#x27;s great for defending against &quot;flashbangs&quot; (when a new tab burns your eyes with a blank white screen).<p>0: <a href="https:&#x2F;&#x2F;github.com&#x2F;yshui&#x2F;picom&#x2F;blob&#x2F;ae73f45ad9e313091cdf720d0f4cdf5b4eb94c1a&#x2F;picom.sample.conf#L338-L343">https:&#x2F;&#x2F;github.com&#x2F;yshui&#x2F;picom&#x2F;blob&#x2F;ae73f45ad9e313091cdf720d...</a>

&gt; 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<p>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.

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&#x27;s how it&#x27;s always behaved.<p>It shouldn&#x27;t be too hard to fix if you want to try, either; check client-&gt;ignoreCount &gt; 0 when handling X_NOTIFY_ERROR before calling CloseDownClient.

By Xorg standards, &quot;8 years old&quot; is basically brand new.

&gt; 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&#x27;s still possible with a remote ssh connection, and gdb scripting, but it&#x27;s inconvenient.<p>I will definitely look into eBPF and uprobe mentioned in the article, I don&#x27;t know about them. But wouldn&#x27;t something like XNest (or XWayland?) help with debugging X? You&#x27;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.

&gt; It&#x27;s still possible with a remote ssh connection, and gdb scripting, but it&#x27;s inconvenient.<p>In this situation, don&#x27;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&#x27;s not clear if that option was considered.

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

&gt; 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<p>There are a lot of WMs who offer a window list (twm, fvwm). Maybe the guy shall take a look how they do it.<p>And requests to the X server are not syncroneus.

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

Planning on fixing this bug? :-)

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

In Xorg timescales that&#x27;s probably one of the youngest bugs :D

I don’t understand why mention he was using .NET with Wine if not going to tell us why. Just silly<p>EDIT: Downvote but don&#x27;t respond. Even sillier!