Xlib-felhantering
Varför ett X-program kan dö av ett fel i en begäran som skickades tjugo anrop tidigare, och vad XSetErrorHandler och -sync gör åt saken.
Xlib buffrar sina förfrågningar och väntar inte på svar om det inte behövs, så när servern avvisar en – BadWindow för ett fönster som redan stängts, BadMatch för en pixmap med fel djup, BadAccess, BadAlloc, BadValue – kommer felet tillbaka som en händelse långt efter det anrop som orsakade det. Standardhanteraren skriver ut "X Error of failed request" med felkod, opkod (Major opcode 20 (X_GetProperty)), resurs-ID och två löpnummer, och avslutar programmet. Löpnumren är ledtråden: det för den felande begäran jämfört med det aktuella säger hur långt efter man ligger.
XSetErrorHandler byter ut hanteraren mot en egen, och nästan varje fönsterhanterare gör det, eftersom ett program kan förstöra sitt fönster mellan det att hanteraren fått veta om det och hunnit agera; den kapplöpningen går inte att vinna, bara att ignorera. XSetIOErrorHandler tar hand om det andra fallet, att anslutningen bryts, och därifrån finns ingen återvändo. För felsökning gör XSynchronize eller Xt-flaggan -sync att varje begäran väntas in, så att felet landar i rätt anrop och en brytpunkt på _XError i gdb visar var; priset är en rundresa per anrop. XCB byggde om modellen: fel kommer som svar på den begäran som orsakade dem, hämtas med xcb_request_check eller ur händelsekön, och det finns ingen global hanterare att glömma att sätta.