Re: [platform-swt-dev] Xlib: unexpected async reply (sequence 0xHEX)!

[Steve Northover <Steve_Northover@xxxxxxxxxx>]

This kind of error is almost certainly
caused by multiple threads in Xlib.  Graphics operation can happen
from any thread.  It is only widget operations that need to execute
in the UI thread.  SWT/Fox needs to deal with this hopefully using
the "Fox threading story" (whatever that is).  In the past,
we tried to use Xlib's XInitThreads() for the X/Motif port but this caused
hangs in other components (Printing, Input Method Editor) because the locks
were not re-entrant.  There were other reasons that XInitThreads()
could not be used that escape me but could probably be found by searching
Bugzilla.

"Ivan Markov" <ivan.markov@xxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx

03/17/2004 05:54 AM

Please respond to
platform-swt-dev

To	platform-swt-dev@xxxxxxxxxxx
cc
Subject	[platform-swt-dev] Xlib: unexpected async reply (sequence 0xHEX)!

Greetings,
 
While slowly moving SWT/Fox (swtfox.sf.net) to 3.0 compatibility,
I eventually got stuck with this error.
 
Here's how it happens:
 
- Eclipse 3.0 M5 or later required (may happen with earlier
milestones too - not sure; does NOT happen with Eclipse 2.X)
- This message appears, but only _sometimes_, when Eclipse+SWT/Fox
is started - jst after the main window is mapped. Then the window is not
painted at all, but the CPU consumption is low.
 
- This happens more frequently when  Eclipse+SWT/Fox
is started for debugging.
- In debugging when I suspend all all threads, the top
of stack trace of the SWT event thread looks very much like the stacktrace
reported by Christophe here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=23472
(happened approx. one year ago)
- All other threads seem to sleep or wait on locks..
 
From what I've heard, these types of messages are reported
by Xlib when x11 package corruption happens, as a result of calling Xlib
from one thread, while another is already inside XLib.
 
This may happen if SWT is called from the wrong thread
(but there are guards in all SWT methods against this) or if a Unix signal
handler calls into XLib. Neither of these seems probable to me. _However_
there may be some race condition involved after all, because every time
this happens, I see the small orange progressbar of a background task drawn..

 
So any insignt on what the problem+fix was for the similar
23472 bug in Eclipse 2+SWT/GTK whould be greatly appreciated - it may help
me chasing the issue. Christophe has reported in the comments of the bug
that it is fixed since build 20030206,
but without any additional details.
 
Yes, I know the bug I'm referring to is fixed almost one
year ago. Still, anyone?
 
Thanks,
Ivan