Comment 10 for bug 901675

The failure is an assertion being hit in libxcb rather than a segfault, which implies that the library isn't bugged itself but rather it's catching a fault higher up in the system.

The xcb assertion code is:

   if (XLIB_SEQUENCE_COMPARE(event_sequence, >,
                                                  dpy->request))
   {
                                throw_thread_fail_assert("Unknown sequence "
                                                         "number while "
                                                         "processing queue",
                                                xcb_xlib_threads_sequence_lost);

There is a big warning in the comments above this code:

/* Thread-safety rules:
 *
 * At most one thread can be reading from XCB's event queue at a time.
 * If you are not the current event-reading thread and you need to find
 * out if an event is available, you must wait.
 *
 * The same rule applies for reading replies.
 *
 * A single thread cannot be both the the event-reading and the
 * reply-reading thread at the same time.
 *
 * We always look at both the current event and the first pending reply
 * to decide which to process next.
 *
 * We always process all responses in sequence-number order, which may
 * mean waiting for another thread (either the event_waiter or the
 * reply_waiter) to handle an earlier response before we can process or
 * return a later one. If so, we wait on the corresponding condition
 * variable for that thread to process the response and wake us up.
 */