[Xcb] Launchpad bugs mentioning dpy->last_request_read

[Jamey Sharp]

CC'ing the xcb list in hopes that somebody there will have a clever
idea about Python, tolerating application mistakes, or both.

On Wed, May 5, 2010 at 3:08 AM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> Jamey Sharp [2010-04-15 15:00 -0700]:
>> All those I could find look like one of two cases: Either the app
>> called Xlib from multiple threads without calling XInitThreads first;
>> or it opened a Display, fork()ed, and used the Display from both
>> processes. Both would be bugs in the application.
>
> Ah, indeed that makes sense, thanks! I updated
> https://launchpad.net/bugs/419501  accordingly.

Regarding Robert Schroll's follow-up comment: I'm guessing the Python
bindings for both Gtk and Qt call XCloseDisplay when the garbage
collector says the PyGtk/PyQt objects aren't in use any more. If an
app creates one of those objects and then forks, both processes have
references to separate copies of the same objects, but only one
process actually continues using it; the other will eventually GC it.
XCloseDisplay tries to issue some requests, so if that gets called
from the garbage collector it will either detect that it received the
wrong response (because the other process issued requests first) or it
will screw up the other process by issuing requests first. That would
trigger this assertion in one process or the other.

You can test that hypothesis by commenting out the XCloseDisplay call
in the Python finalizer, assuming there is one, and seeing if the
assert goes away. In most applications this is actually harmless as
they usually exit immediately after closing the display, which will
free all the same resources automatically; but in principle removing
the XCloseDisplay call leads to a memory leak, so this isn't really a
fix.

Assuming this hypothesis is correct, what you really need is the
ability to have some Python objects not be cloned across fork, but I
don't know if that's feasible. Even just arranging for the X file
descriptor to be closed on fork would solve the problem, as long as
Gtk and Qt install an Xlib I/O error handler (otherwise Xlib will kill
the child process anyway when it discovers the fd is closed). Of
course Unix only gives us a close-on-exec flag, not close-on-fork, so
it'd have to be some Python-specific facility, I guess.

Robert's point about relaxing the assert is well-taken; obviously
we've come to the same conclusion for similar problems before. I'm not
convinced the result would be stable in this case though: there's a
sort of race between the garbage collector in the child process and
the GUI code in the parent, and I'd expect the parent to either hang
or hit some different assert if this one is removed. Xlib before XCB
was admittedly more tolerant of unaccounted-for responses; I don't see
a way to do that now.

Hope that helps,
Jamey