|Summary:||Reproducible server crash related to SD animated cursor|
|Product:||xorg||Reporter:||Tom Jaeger <ThJaeger>|
|Component:||Server/General||Assignee:||Peter Hutterer <peter.hutterer>|
|Status:||RESOLVED FIXED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
|Bug Depends on:|
Description Tom Jaeger 2008-12-11 17:16:14 UTC
When using xserver-18.104.22.168, occasionally a second cursor will appear on the screen whose position and background doesn't change after that (I'll make a screenshot the next time this happens). When I close the client whose window this happened on, the server crashes. Backtrace below --- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7bca6b0 (LWP 5389)] 0x08072509 in dixLookupPrivate (privates=0xb9b0330, key=0x81f3e60) at ../../dix/privates.c:79 79 return *key && *privates && (gdb) bt #0 0x08072509 in dixLookupPrivate (privates=0xb9b0330, key=0x81f3e60) at ../../dix/privates.c:79 #1 0x08111539 in miDCPutUpCursor (pDev=0xa1e2c28, pScreen=0xa1b3418, pCursor=0xacbb158, x=764, y=826, source=0, mask=16777215) at ../../mi/midispcur.c:449 #2 0x08121f2b in miSpriteRestoreCursor (pDev=0xa1e2c28, pScreen=0xa1b3418) at ../../mi/misprite.c:1025 #3 0x081223fd in miSpriteBlockHandler (i=0, blockData=0x0, pTimeout=0xbf8b6718, pReadmask=0x81f41e0) at ../../mi/misprite.c:525 #4 0xb7ad3e75 in ?? () from /usr/lib/xorg/modules/drivers//intel_drv.so #5 0x081799cb in AnimCurScreenBlockHandler (screenNum=0, blockData=0x0, pTimeout=0xbf8b6718, pReadmask=0x81f41e0) at ../../render/animcur.c:222 #6 0x08143368 in compBlockHandler (i=0, blockData=0x0, pTimeout=0xbf8b6718, pReadmask=0x81f41e0) at ../../composite/compinit.c:158 #7 0x080908e8 in BlockHandler (pTimeout=0xbf8b6718, pReadmask=0x81f41e0) at ../../dix/dixutils.c:384 #8 0x0812fd74 in WaitForSomething (pClientsReady=0xa2a1060) at ../../os/WaitFor.c:215 #9 0x0808c9ee in Dispatch () at ../../dix/dispatch.c:367 #10 0x0807196d in main (argc=10, argv=0xbf8b6864, envp=0x0) at ../../dix/main.c:383
Comment 1 Peter Hutterer 2008-12-11 18:07:59 UTC
you don't happen to have a reproducable testcase? Any particular client that causes it?
Comment 2 Tom Jaeger 2008-12-11 18:25:12 UTC
Sorry, I don't know how to reproduce it. It's happened with several different clients before. I'll let you know when I find out more.
Comment 4 Tom Jaeger 2008-12-11 18:33:42 UTC
I can reproduce it now. It happens on any kind of drag and drop -- but, only when using my trackpoint, the bug doesn't appear when I'm using the wacom pen.
Comment 5 Tom Jaeger 2008-12-11 22:14:22 UTC
I can only reproduce the bug when the Xi device belonging to the track point is grabbed, for example when the attached client is running.
Comment 6 Tom Jaeger 2008-12-11 22:15:09 UTC
Created attachment 21082 [details] client that grabs the track point Xi device
Comment 7 Tom Jaeger 2008-12-11 22:17:21 UTC
Created attachment 21083 [details] client that grabs the track point Xi device
Comment 8 Tom Jaeger 2008-12-20 09:39:25 UTC
Just updated to the latest commit on server-1.6-branch, and the bug disappeared. Thanks. Xi grabs with GrabModeSync still behave differently on my stylus than on my track point, though.
Comment 9 Peter Hutterer 2008-12-21 23:25:22 UTC
Closing as fixed then. Please open a separate bugreport (if it isn't open already) for the other issue.
Comment 10 Tom Jaeger 2009-01-03 18:26:17 UTC
Reopening, see http://email@example.com/msg03537.html I can also reproduce it myself using easystroke, timeout gestures and the compiz cube rotation plugin, but only when the current cursor is animated. I'll open a bug for the other issue as soon as I find the time to investigate it more.
Comment 11 Tom Jaeger 2009-01-05 21:37:33 UTC
Created attachment 21710 [details] [review] fix This patch (plus http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.6-branch&id=0d12c44d832b98da10dccc3b8bac7676d8ea2c96) fixes the issue for me. What happens in my case is that during processing of an UngrabDevice request, DeactivatePointerGrab calls PostNewCursor with a slave device as its argument, which AnimCurDisplayCursor can't handle. Similar fixes probably need to be applied to AnimCurSetCursorPosition and AnimCurRecolorCursor.
Comment 12 Peter Hutterer 2009-01-05 22:16:26 UTC
This patch just papers over the issue though. In theory, cursors for floating SDs should be just like any cursor but not visibly rendered to the screen. So the question is more why it crashes and that looks more like there's something screwed with the private system (something isn't stored properly, or a key is wrong, or something like that).
Comment 13 Tom Jaeger 2009-01-06 08:36:30 UTC
I see, so the patch doesn't handle floating SDs correctly, but something similar is still needed to get correct behavior on attached SDs: Otherwise the SD's animated cursor keeps overwriting the correct cursor associated with the MD. The crash looks like a dangling pointer to me: This is where the animated cursor is freed: Breakpoint 2, FreeCursor (value=0x9c0a548, cid=58720462) at ../../dix/cursor.c:125 125 for (nscr = 0; nscr < screenInfo.numScreens; nscr++) (gdb) bt #0 FreeCursor (value=0x9c0a548, cid=58720462) at ../../dix/cursor.c:125 #1 0x0807448c in FreeResource (id=58720462, skipDeleteFuncType=0) at ../../dix/resource.c:561 #2 0x08087d23 in ProcFreeCursor (client=0x9a75408) at ../../dix/dispatch.c:2956 #3 0x0808cd7f in Dispatch () at ../../dix/dispatch.c:437 #4 0x08071b3d in main (argc=10, argv=0xbfe273d4, envp=Cannot access memory at address 0x20000007 ) at ../../dix/main.c:383 And here it is still accessed from the block handler: Program received signal SIGSEGV, Segmentation fault. 0x3a313158 in ?? () (gdb) bt #0 0x3a313158 in ?? () #1 0x0807242c in dixFreePrivates (privates=0x9bbea10) at ../../dix/privates.c:213 #2 0x080815ba in FreeCursor (value=0x9bb99a8, cid=0) at ../../dix/cursor.c:130 #3 0x080f01b7 in xf86_use_hw_cursor_argb (screen=0x8efaab0, cursor=0x9bbe0b8) at ../../../../hw/xfree86/modes/xf86Cursors.c:485 #4 0x080f787a in xf86CursorSetCursor (pDev=0x9128800, pScreen=0x8efaab0, pCurs=0x9bbe0b8, x=<value optimized out>, y=<value optimized out>) at ../../../../hw/xfree86/ramdac/xf86Cursor.c:332 #5 0x0811b8f8 in miPointerUpdateSprite (pDev=0x9128800) at ../../mi/mipointer.c:407 #6 0x0811bb3d in miPointerDisplayCursor (pDev=0x9128800, pScreen=0x8efaab0, pCursor=0x9bbe0b8) at ../../mi/mipointer.c:198 #7 0x08149156 in CursorDisplayCursor (pDev=0x9128800, pScreen=0x8efaab0, pCursor=0x9bbe0b8) at ../../xfixes/cursor.c:148 #8 0x0817a205 in AnimCurScreenBlockHandler (screenNum=0, blockData=0x0, pTimeout=0xbfe27288, pReadmask=0x81f51e0) at ../../render/animcur.c:203 #9 0x08143618 in compBlockHandler (i=0, blockData=0x0, pTimeout=0xbfe27288, pReadmask=0x81f51e0) at ../../composite/compinit.c:158 #10 0x080909b8 in BlockHandler (pTimeout=0xbfe27288, pReadmask=0x81f51e0) at ../../dix/dixutils.c:384 #11 0x08130024 in WaitForSomething (pClientsReady=0x9124ec0) at ../../os/WaitFor.c:215 #12 0x0808cabe in Dispatch () at ../../dix/dispatch.c:367 #13 0x08071b3d in main (argc=10, argv=0xbfe273d4, envp=0x0) at ../../dix/main.c:383 (gdb) up 8 #8 0x0817a205 in AnimCurScreenBlockHandler (screenNum=0, blockData=0x0, pTimeout=0xbfe27288, pReadmask=0x81f51e0) at ../../render/animcur.c:203 203 (void) (*pScreen->DisplayCursor) (dev, (gdb) print animCurState[dev->id].pCursor $5 = (CursorPtr) 0x9c0a548
Comment 14 Tom Jaeger 2009-02-12 17:21:09 UTC
Easy way to reproduce the issue: Adjust the above program to grab the XI slave device of your choice, and then, in firefox, repeatedly reload a website that takes a while to load (so that an animated cursor is shown) by using a menu (e.g. the history menu or the most visited menu). Now if you place the mouse in another window, that window's cursor will be instantly overwritten by the animated cursor. The X server will crash as soon as firefox is closed.
Comment 15 Peter Hutterer 2009-02-28 02:11:48 UTC
Thanks Tom. Just to give you a heads-up, it'll take me a while to get to this bug, half the input system is reworked and cleaned up, so I'm holding back with bugs until that work is done.
Comment 16 Peter Hutterer 2009-05-10 23:36:44 UTC
Tom: can you please give me an update if you still see this issue? I just tried it (with thunderbird instead of firefox) on my XI2 branch and couldn't reproduce it.
Comment 17 Tom Jaeger 2009-05-11 20:33:40 UTC
I'm hopelessly bad at building X servers from source. I would guess, however, that you can reproduce the bug by calling XChangeDeviceCursor on an attached SD with an animated cursor as argument.
Comment 18 Tom Jaeger 2009-05-11 20:35:12 UTC
Created attachment 25782 [details] potential test case Since I don't have an xi2 server running, I couldn't test this and I'm sure it needs a few adjustments.
Comment 19 Tom Jaeger 2009-05-11 20:37:10 UTC
On second thought, we probably need to call XChangeDeviceCursor on the root window to see the bug.
Comment 20 Peter Hutterer 2009-08-17 21:54:15 UTC
can you give me another update on this? Have you seen this bug recently? I just tried your test program on the root window + the window, with an attached and floating slave device and didn't see any crashes.
Comment 21 Tom Jaeger 2009-08-17 22:02:48 UTC
(In reply to comment #20) > can you give me another update on this? Have you seen this bug recently? I just > tried your test program on the root window + the window, with an attached and > floating slave device and didn't see any crashes. The issue of an animated SD cursor living longer than it should and overriding the correct cursor still exists on master (I'll see if I can create a test case when I have time), but it's not very critical as it doesn't cause crashes any longer and a lot less annoying since it usually goes away fairly quickly as a result of switching the application or similar.
Comment 22 Peter Hutterer 2009-08-17 22:07:56 UTC
I'm fixing this right now, the server should return BadDevice for any ChangeCursor call on an SD, only master pointers can have cursors set. that's one part of the fix, the other one is obviously to remove the device-specific cursor when the master pointer disappears.
Comment 23 Peter Hutterer 2009-09-01 23:31:36 UTC
Fixed, AFAICT. Commit is 65354e5a698a5b527db09afc431110afba0e14b2. Please reopen if you can still reproduce this.