"Xlib: unexpected async reply" with threaded RTS and --sync command line parameter

[guest]

A trivial program which uses unsafeInitGUIForThreadedRTS, and doesn't even start additional threads, causes the above error message when started with the "--sync" command line parameter. It has to be compiled with "-threaded", but multithreading doesn't need to be enabled at runtime for the error to occur. The same problem occurs even without the "--sync" parameter, but only in a much more complex program. All the parameter does is tell X to report errors synchronously.

Calling XInitThreads at the start of main makes the error disappear, which indicates that Haskell calls Gtk (which in turn calls X) from multiple OS threads.

The attached archive contains three versions of the same program:

1. broken.hs prints the error and hangs. Some fierce resizing (i. e. Expose events) may be necessary to trigger the error.
2. working.hs merely adds a call to XInitThreads and doesn't hang regardless of the amount of resizing.
3. test.c is an equivalent program in C, which works fine without calling XInitThreads.

[guest]

Example reproducing the error and two working (almost-)equivalents

[duncan]

Thanks for the report and detailed investigation.

So apparently the expose callback is happening in a different thread to the one that called initGUI and mainGUI. I had thought that could not happen. We'll need to check the behaviour with the ghc rts devs.

[pgavin]

This is very old. I think its been fixed. If not, please open a new bug.

[guest]

Why should anyone open a new bug? The description and test case are correct, there's no point writing it up again.

[axel]

The reason for this error is that the garbage collector finalizes Gtk objects from different threads. Since some Gtk objects hold X11 resources, these resources are then freed from different OS threads, leading to the observed errors. This is now fixed in the darcs repository by freeing all Gtk objects in an idle callback from the main Gtk loop.