mieqProcessDeviceEvent make calls to mieqEnque with signals enabled - freezes Xorg server - multi-screen

[Peter Hutterer]

On Tue, May 17, 2011 at 05:13:37PM -0500, Donald Kayser wrote:
> Thanks for the quick response Jeremy. I was aware that I would miss
> events during this test, but that was better than freezing. I have
> not tried 1.10.x, but I will. We are trying to release a product
> soon and changing to a new server and distribution is not
> straightforward or the best move on our part. I might have to
> consider any other solution for the short term. I am glad to hear
> that we are not the only ones to have this problem and that it might
> already be solved. I will look further at 1.10.x and go from there.

I think this bug may still be there (possibly in a different incarnation) in
1.10. I haven't had any success reproducing it yet though.
I know at least one of these got fixed in the last couple of server
versions, but I can't seem to find the commit for it now.

I suppose the quickest fix is to put OsBlockSignals() and OsReleaseSignals()
around the part that must not be interrupted and rewrite it to be as short
as possible. If you have a good description of the bug I'd love to hear it
so we can look at a proper fix.

Cheers,
  Peter

> On May 17, 2011, at 4:49 PM, Jeremy Huddleston wrote:
> 
> >Ignoring SIGIO will just result in dropped events.  I seem to
> >vaguely recall that this issue was addressed at some point in the
> >past year or two since 1.7.x was active.  Have you tried 1.10.x or
> >master?
> >
> >On May 17, 2011, at 13:34, Donald Kayser wrote:
> >
> >>I am developing a system that include's the debian/squeeze
> >>distribution of xorg-server, version 1.7.7. I have come across a
> >>scenario where mouse movements on one screen and a touch on
> >>another screen will cause the Xorg process to freeze in an
> >>infinite loop in the function mieqProcessInputEvents(). I have
> >>traced the problem down to a small window during which a call to
> >>mieqProcessDeviceEvent can be interrupted by a signal and mess
> >>up the miEventQueue.head and tail. It appears that in some place
> >>in this stack a new event is being enqueued while the screen is
> >>changing and device messages get swapped to the wrong screen and
> >>back and forth.
> >>
> >>I put a global variable in mieqProcessDeviceEvent to indicate to
> >>mieqEnqueue to ignore data until finished. This has solved the
> >>problem as a test. I am now writing the code to ignore the SIGIO
> >>signal during mieqProcessDeviceEvent and test this approach
> >>also.
> >>
> >>Does anyone have a similar problem or advice?
> >>
> >>Thanks
> >>Donald Kayser
> >>xorg at kayser dot net
> >>
> >>
> >>_______________________________________________
> >>xorg at lists.freedesktop.org: X.Org support
> >>Archives: http://lists.freedesktop.org/archives/xorg
> >>Info: http://lists.freedesktop.org/mailman/listinfo/xorg
> >>Your subscription address: jeremyhu at freedesktop.org
> >>
> >
> >_______________________________________________
> >xorg at lists.freedesktop.org: X.Org support
> >Archives: http://lists.freedesktop.org/archives/xorg
> >Info: http://lists.freedesktop.org/mailman/listinfo/xorg
> >Your subscription address: xorg at kayser.net
> >
> 
> _______________________________________________
> xorg at lists.freedesktop.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.freedesktop.org/mailman/listinfo/xorg
> Your subscription address: peter.hutterer at who-t.net
>