Comment 49 for bug 419501

> "Both would be bugs in the application."

I would like to point out my test case again (comment 31), a simple pyGTK app that displays the same problem. While it may have a bug (please point it out if you see it!), I find that unlikely given how short and simple it is, and because it works perfectly in Ubuntu < Karmic. (FWIW, I tried scattering gtk and gobject threads_init() calls throughout the test case, to no avail.)

As best I can tell from their diffs, python-gasp did not fix this problem; they worked around it by holding off on importing gtk. I think this is similar to the work-around in comment 33. From their NEWS file ["* Work around xlib threadinb bug (LP: #41950)"], it seems that they don't consider this a real bug fix. I don't think that this method will work in any application that must fork in response to user action.

Thus, it seems to me that the bug is lower than the application level -- it could be in the language bindings (pyGTK, in my case), the toolkit (GTK), or in X. The only one shared between my test case and apport-kde is X. But I suppose it is possible that both GTK and QT introduced the same bug at the same time.

If I may present a hypothesis unfettered by evidence: Perhaps (py)GTK and (py)QT have long been doing something technically illegal but practically benign. This went undetected until Karmic, when an upgrade to libxcb tested for this condition in an assert statement. Obviously, the correct long-term fix is to find what the toolkits are doing wrong and fix that, but in the short term it might make sense to relax the assertion checking in libxcb. The obvious way to test this is to comment out the assertion, run it, and see if anything breaks. But I can't even figure out which package has xcb_io.c in it, so I'm probably not the person to check this.

Anyway, should I reopen bug #518269 and file it against GTK, should this bug also be linked to GTK, or should I just wait until we have firm evidence that the problem is at the toolkit level instead of X?