[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Xlib: unexpected async reply (sequence 0xHEX)!


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