On Fri, 2017-08-04 at 05:55 +0000, Subrata Dasgupta wrote:
> Hi Ajax,
> Why every time XErrorEvent.serial = 2422603788. Does not it mean
> application is facing problem only after a certain number of requests
> has been made??
It means the error structure points to a place in memory that
consistently contains that value, yes. But an XErrorEvent is only sent
for protocol errors, not disconnections, so I'm pretty sure that's just
a coincidence. To wit:
> Can you please provide where from I get information about the
> error_code, request_code and minor_codes of XErrorEvent structure
> because I want to understand the meaning of the following codes.
> XErrorEvent.error_code = 84
> XErrorEvent.request_code = 131
> XErrorEvent.minor_code = 4
You can discover the mappings for these from 'xdpyinfo
-queryExtensions', which will list the error and event bases and
extension opcode for each extension. Extension codes are assigned
dynamically so this will depend on the specific server you're talking
to. On my machine:
% xdpyinfo -queryExtensions | grep 131
XInputExtension (opcode: 131, base event: 66, base error: 129)
The "error code" is also used for event codes, and xinput does indeed
have a lot of events, but that reinforces my point. Extension events
are between 64 and 127, and extension errors are between 128 and 255.
This event says error_code = 84, which means (assuming you trust that
the XErrorEvent struct was pointing to valid data) that what you're
looking at is _not a protocol error_.
> For a huge X application this should not be a coincidence. Most
> importantly this behavior seems to be related with the bug 71338.
> When I checked my libxcb.so and libX11.so it seems 4 functions
> proposed for the fix for 71338(xcb_send_request64,
> xcb_discard_reply64, xcb_wait_for_reply64, xcb_poll_for_reply64) are
> present within the libxcb.so but libX11 do not use the function
> xcb_send_request64 or xcb_discard_reply64 within it. Why this is so
Those are the functions responsible for processing data from the
server, so of course they will be in the backtrace for any fatal
email@example.com: X.Org support
Your subscription address: %(user_address)s