[Xlib] Ignoring BadAccess errors

[Owen Taylor]

GTK+ is already using Xlib at a pretty low level - see gdk/x11/gdkasync.c.

So just, say, copy what
https://cgit.freedesktop.org/xorg/lib/libX11/tree/src/GetIFocus.c does
and check the return value of _XReply() - if it's 0, then you got a
BadAccess. (Or some other call if GetInputFocus doesn't do what you
want.)

Going to XCB would be the clean solution, but I don't see introducing
XCB usage into GTK+ as a good idea at this point - there are almost
certainly subtle traps if mixing together XLib and XCB usage.

Owen

On Tue, Apr 20, 2021 at 7:30 AM Nekun <nekokun at firemail.cc> wrote:
>
> Hi all.
>
> Can somebody explain me why BadAlloc and BadAccess errors are ignored in
> Xlib reply processing, but only in certain conditions? As I can see
> (maybe I misunderstood something, please correct), in _Xreply:
> https://cgit.freedesktop.org/xorg/lib/libX11/tree/src/xcb_io.c#n655 ,
> after sending a request, at first we process pending responses in input
> buffer and handle it without any exceptions and then we process the last
> response and ignore some errors: BadName and BadFont in some conditions
> described in the Xlib spec:
> https://www.x.org/releases/current/doc/libX11/libX11/libX11.html#Using_the_Default_Error_Handlers
> , and, suddenly, completely ignore BadAccess and BadAlloc. I don't found
> any references for that behavior. In result, I can't trap these errors
> with my error handler if an Xlib request wrapper calls _Xreply
> explicitly. Some wrappers, such as XBell, writes a request to output
> queue, calls the sync handler and then errors are handled without
> exception because XSync adds InputSetFocus to queue, so the target
> request is processed with no-exception logic described above. This issue
> arised when I worked on fixing the broken untrusted context check in GTK
> (GDK) at display opening. I need a function which robustly returns an
> error when we in untrusted context, which returned exactly when client
> is untrusted and not for any other reasons, and throw in the gdk_x_error
> trap. Tried XListHosts and failed for reasons described above. Maybe I
> can use a return value of some function instead of error handling? Seems
> like X11 security extension more often returns fake values for untrusted
> clients rather than errors, but not sure that is possible to distinguish
> between a fake value and a real in any response. Stucked here.
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
>