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@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
