I just ran the full classlib test on HEAD in Ubuntu 9.04 with GNOME desktop running and none of these assertions popped up. They only seem to pop-up when running the tests using Xvfb. I don't know what this means that the problem isn't an issue or if it's just delayed.
-Nathan On Mon, May 18, 2009 at 8:17 AM, Mark Hindess <[email protected]> wrote: > > During the M9 freeze there was some discussion [0] about HARMONY-6123 [1]. > > I've had a look at this issue. I've attached a patch to the above > JIRA that attempts to add calls to XLockDisplay/XUnlockDisplay around > a single call (XNextEvent) that appeared in the backtrace for this > bug. Sadly, it causes a deadlock with one thread waiting with the > (new) lock in XNextEvent and another (presumably trying to obtain a lock) > in XSendEvent. > > (Aside: Why does XNextEvent require explicit lock calls when XSendEvent is > clearly making them implicitly/internally?) > > Since XNextEvent is intended to block until an event becomes available *and* > is required to hold a display lock, I can't see how this can easily be > resolved. Google reveals that some projects solve this by: > > 1) doing all Xlib calls on a single thread, > 2) using XPending and busy wait (loop/sleep) waiting for an event or > 3) rewriting to use the new xcb/xcbutil instead of xlib > > I'm not particularly enthusiastic about any of these - 2 is least effort but > horrible. > > Anyone have any bright ideas or comments? > > Regards, > Mark. > > [0] http://markmail.org/message/mcngtqjtdphwno3w > [1] https://issues.apache.org/jira/browse/HARMONY-6123 > >
