update-manager assert failure: python: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

StacktraceTop:
 __assert_fail_base (fmt=<optimized out>, assertion=0x7f20d7ceead8 "!xcb_xlib_threads_sequence_lost", file=0x7f20d7ceed92 "../../src/xcb_io.c", line=<optimized out>, function=<optimized out>) at assert.c:94
 __GI___assert_fail (assertion=0x7f20d7ceead8 "!xcb_xlib_threads_sequence_lost", file=0x7f20d7ceed92 "../../src/xcb_io.c", line=273, function=0x7f20d7ceeeb8 "poll_for_event") at assert.c:103
 poll_for_event (dpy=<optimized out>) at ../../src/xcb_io.c:270
 poll_for_response (dpy=0xc64700) at ../../src/xcb_io.c:288
 _XEventsQueued (dpy=0xc64700, mode=<optimized out>) at ../../src/xcb_io.c:362

Status changed to 'Confirmed' because the bug affects multiple users.

FYI HACK :: sudo aptitude seems like a good work around.

This bug and its duplicates seem to have happened during distribution upgrades:

10:24:37 - flash:[...ents/canonical/launchpadlib] ./bug-check-duplicate-properties.py --bug 930004 --keys UpgradeStatus
LP: #930004 has a total of 6 duplicates
UpgradeStatus
  [1] Upgraded to precise on 2012-02-12 (0 days ago): 931064
  [1] Upgraded to precise on 2012-02-11 (0 days ago): 930498
  [3] Upgraded to precise on 2012-02-10 (0 days ago): 930243, 930257, 930417
  [1] Upgraded to precise on 2012-02-13 (0 days ago): 931537

Several of the bugs have the following in VarLogDistupgradeAptlog.txt:

MarkUpgrade() called on a non-upgrable pkg: 'brasero'
ERROR:root:Upgrading 'brasero' failed
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
python: ../../src/xcb_io.c:273: poll_for_event: Assertion `! xcb_xlib_threads_sequence_lost' failed.

The error message "Unknown sequence number while processing queue" occurs in a chunk of text that has this big fat warning in front of it, about threading safety in client 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.
 */

This seems to suggest perhaps this client application could have some faulty logic in its thread handling as relating to the xcb calls?

Btw, xtrace may be useful for helping diagnose what the client is doing exactly.

Bug 901675 (apport) and bug 938713 (software-center) and bug 927727 (bamf) all have similar assertions.

Bug #933988 (java) also has this assertion.

The two machines I've upgraded from precise to quantal (yesterday & today) have both experienced this bug, resulting in the release-upgrader being killed, and requiring manual editing of files within /var/lib/dpkg/ and use of aptitude to complete the upgrade.