Ubuntu Wiki

Symptoms

• The client app crashes with a message like this one (Gdk):

Gdk-ERROR **: The program '<PROGRAM>' received an X Window System error.
This probably reflects a bug in the program.
The error was '<SOME_ERROR>'.
  (Details: serial <AA> error_code <B> request_code <CC> minor_code <D>)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
aborting...

• Or like this (Qt):

X Error: <SOME_ERROR>
  Major opcode:  <CC>
  Minor opcode:  <D>
  Resource id:  0x0
Failed to open device

Non-Symptoms

• The X Server itself locks up or crashes. This is a much more severe issue. In this case your app has gotten X into some funky state. See some of the other X/Troubleshooting pages to sort this out.

How It Works

X11 is a client/server protocol. Client applications (like Gdk or Qt programs) send requests to the X server to update the screen, get information, and so on. The server does its best to honor these requests, however in some cases it can't be done, and an X error is returned to the client instead.

It's actually quite common and normal for the X server to return errors to let the client know certain things can't be done. Most of the time, typically the client app (or one of its underlying libraries) would listen for that error and handle it appropriately.

So what you're seeing with the above error message is a situation where an unexpected error was returned which the client app was *not* prepared to handle. There are a few different angles for dealing with it.

Tracing X Protocol Communication

The program xtrace can be used to examine the request/response traffic between your client and the X Server.

More info about xtrace can be found at Debian

(A walkthrough usage example would be handy here...)

Problem: Client App Needs to Handle X Error

Linux systems exist in great diversity, and it is quite usual for people to run a client app on a system which is very different from the one the app was developed on. Maybe compositing or DRI is turned off and thus unavailable, or the system has an unusual architecture. Thus client apps need to be prepared to handle the range of errors that X can return, and to trigger an appropriate action (such as displaying an error dialog, or using alternate functionality.)

Here's a snippet of code showing one way to catch x11 errors in gdk (stolen from Bug #521371):

  gdk_error_trap_push();

  resources = XRRGetScreenResources (screen_x11->xdisplay,
                                     screen_x11->xroot_window);
  gdk_flush();
  
  if (gdk_error_trap_pop())
    return FALSE; 
  
  if (!resources)
    return FALSE;

Problem: Client App Speaks Wrong Protocol

The X Server (specifically, libx11/libxcb) defines the protocol language used and commands that client applications can use in communicating with the server. So as a first order analysis, doublecheck that the API (function calls, parameter types and values, etc.) are consistent with the shipped version of libx11. In general, this can be checked by referring to the installed man page for the given X command.

Another thing to check is if the protocol has changed, such as due to a bug in the API or other development activity. Generally this situation would only arise in the development version of Ubuntu when we upgrade to a new xorg-server and/or libx11 package. This should be a pretty rare situation that it'd result in breakage at the client level, but it does happen from time to time. If you suspect a protocol change, upgrading/downgrading these can be done to verify it as the cause of the client breakage.

Problem: X Server Returned an Unexpected Error

In some rare cases, the xserver might return an error code that is not documented in the man page. This is a bug, either in the documentation (package libx11) or the xserver itself (package xorg-server).

Useful information to include in the bug report includes:

• Xorg.0.log after reproducing the issue
• Full backtrace from the client
• xtrace output