From: Carlos Garnacho <[email protected]> The loop above the previous call may end up triggering other handlers attaching to the same function slot, so unwrapping the handler after that could leave the just attached handler in a dangling but not unset state.
This issue was most visible on the XO, where destroying a window with an animated cursor set and running would trigger this inconsistent state, never calling the miSpriteBlockHandler again after the animated cursor is unset. Signed-off-by: Carlos Garnacho <[email protected]> --- render/animcur.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/render/animcur.c b/render/animcur.c index ebc5b8e..9cbba83 100644 --- a/render/animcur.c +++ b/render/animcur.c @@ -143,6 +143,8 @@ AnimCurScreenBlockHandler(ScreenPtr pScreen, Bool activeDevice = FALSE; CARD32 now = 0, soonest = ~0; /* earliest time to wakeup again */ + Unwrap(as, pScreen, BlockHandler); + for (dev = inputInfo.devices; dev; dev = dev->next) { if (IsPointerDevice(dev) && pScreen == dev->spriteInfo->anim.pScreen) { if (!activeDevice) { @@ -180,7 +182,6 @@ AnimCurScreenBlockHandler(ScreenPtr pScreen, if (activeDevice) AdjustWaitForDelay(pTimeout, soonest - now); - Unwrap(as, pScreen, BlockHandler); (*pScreen->BlockHandler) (pScreen, pTimeout, pReadmask); if (activeDevice) Wrap(as, pScreen, BlockHandler, AnimCurScreenBlockHandler); -- 1.8.0.1 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
