Ticket #1112 (closed defect: fixed)

Opened 6 years ago

Last modified 5 years ago

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

Reported by: guest Owned by: somebody
Priority: blocker Milestone: 1.0
Component: general (Gtk+, Glib) Version: 0.9.12
Keywords: threads Cc:

Description

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.

Attachments

threads.tgz (1.0 kB) - added by guest 6 years ago.
Example reproducing the error and two working (almost-)equivalents

Change History

Changed 6 years ago by guest

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

Changed 6 years ago by 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.

Changed 5 years ago by pgavin

  • status changed from new to closed
  • resolution set to fixed

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

Changed 5 years ago by guest

  • priority changed from normal to blocker
  • status changed from closed to reopened
  • resolution fixed deleted
  • milestone set to 1.0

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

Changed 5 years ago by axel

  • status changed from reopened to closed
  • resolution set to fixed

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.

Note: See TracTickets for help on using tickets.