On Mon, Mar 08, 2010 at 08:38:04AM -0800, David Mohr wrote: > On Wed, Mar 3, 2010 at 1:24 PM, Aaron Plattner <[email protected]> wrote: > > On Tue, 2010-03-02 at 22:24 -0800, David Mohr wrote: > >> On Mon, Mar 1, 2010 at 6:07 PM, David Mohr <[email protected]> wrote: > >> > On Mon, Mar 1, 2010 at 3:38 PM, Peter Hutterer > >> > <[email protected]> wrote: > >> >> On Mon, Mar 01, 2010 at 12:41:02AM -0700, David Mohr wrote: > >> >>> On Sun, Feb 28, 2010 at 11:37 PM, Peter Hutterer > >> >>> <[email protected]> wrote: > >> >>> > On Sun, Feb 28, 2010 at 11:29:12PM -0700, David Mohr wrote: > >> >>> >> I'm part of the minory who currently uses a Zaphod style dual > >> >>> >> monitor > >> >>> >> setup with separate X screens for every monitor. When I recently > >> >>> >> upgraded from 7.4 to 7.5, some utilites which I adopted[1] which > >> >>> >> manipulate the mouse cursor started malfunctioning. My two X screens > >> >>> >> are setup to be "apart" so that the mouse does not pass between > >> >>> >> them, > >> >>> >> and I use my utilities to move the mouse between the two screens. > >> >>> >> But > >> >>> >> with 7.5 every now and then a condition is triggered where the mouse > >> >>> >> cursor will just continually jump from screen to screen, keeping > >> >>> >> the X > >> >>> >> server at 100% CPU. I cannot even shut it down using > >> >>> >> CTRL-ALT-Backspace. > >> >>> >> > >> >>> >> I've noticed comments in other threads on this mailing list that > >> >>> >> Zaphod mode is not really supported any more (for completeness' > >> >>> >> sake, > >> >>> >> I'm using the binary Nvidia drivers). So my question is, is there > >> >>> >> value in trying to track down the bug in Xorg which causes the mouse > >> >>> >> to jump back and forth? > >> >>> > > >> >>> > yes. I've seen this myself and I have not yet identified the issue. > >> >>> > it's a > >> >>> > server bug and unrelated to the binary driver. If you can help track > >> >>> > this > >> >>> > issue down, it would be much appreciated. > >> >>> > >> >>> Ok. Unfortunately I have not been able to find reliable conditions for > >> >>> triggering the bug. I'll try again and see what I can find. > >> >> > >> >> i found using a wacom tablet with a xinerama setup and then switch back > >> >> and > >> >> forth triggers it eventually. the problem is the "eventually" bit... > >> > > >> > Yes, it's similar for me. One of the tools I use switches the mouse > >> > over when it hits the edge of the screen, so it's warping the pointer > >> > relatively often. I can't reproduce the problem reliably, but if I > >> > keep going back and forth it doesn't take very long to trigger it. > >> > > >> >>> Is there any way to get good information out of the running X instance > >> >>> once the bug has been triggered? I can only think of sending a signal > >> >>> to get a core dump, but then I'm not sure how much useful information > >> >>> that would contain. > >> >> > >> >> once it happens, gdb in and single-stepping may be the only approach. a > >> >> backtrace would be great already, just to make sure if you're seeing the > >> >> same problem as I am. > >> > > >> > Ugh. Here the trouble begins. When I attach to the process with gdb, > >> > it tells me it's in nvidia_drv.so, which of course doesn't have > >> > debugging symbols. So I can't get a useful backtrace or start to > >> > single step. > >> > >> I tried it a second time and again was only able to break in > >> nvidia_drv.so. I'm wondering if I installed all the right debugging > >> packages. I use debian, so I installed xserver-xorg-core-dbg. Is that > >> sufficient? > >> > >> I don't have much experience with how gdb behaves if there are no > >> debugging symbols available in _part_ of the program. Could it be that > >> I can inspect the X server by setting a breakpoint somewhere and then > >> continuing? > >> If so, what would be a good place to put a breakpoint (I have no clue > >> about X internals)? > > > > Since the cursor is actively changing, you could try putting a > > breakpoint on xf86SetCursor. > > Thanks Aaron, the xf86SetCursor suggestion worked out. Unfortunately I > must admit I'm not sure how to proceed, since the execution path > constantly leads into the closed nvidia_drv module... Here is an > excerpt from my gdb session, maybe this is some help for Peter to > decide whether it's the same bug or not. > > (gdb) break xf86SetCursor > Breakpoint 1 at 0x8185b64: file > ../../../../hw/xfree86/ramdac/xf86HWCurs.c, line 115. > (gdb) cont > Continuing. > > Breakpoint 1, xf86SetCursor (pScreen=0x925a730, pCurs=0x0, x=0, y=0) > at ../../../../hw/xfree86/ramdac/xf86HWCurs.c:115 > 115 { > (gdb) n > 116 xf86CursorScreenPtr ScreenPriv = > (xf86CursorScreenPtr)dixLookupPrivate( > (gdb) n > 121 if (pCurs == NullCursor) { > (gdb) > 116 xf86CursorScreenPtr ScreenPriv = > (xf86CursorScreenPtr)dixLookupPrivate( > (gdb) > 118 xf86CursorInfoPtr infoPtr = ScreenPriv->CursorInfoPtr; > (gdb) > 121 if (pCurs == NullCursor) { > (gdb) > 122 (*infoPtr->HideCursor)(infoPtr->pScrn); > (gdb) > 0xb5ffb8f0 in ?? () from /usr/lib/xorg/modules/drivers/nvidia_drv.so > (gdb) n > Cannot find bounds of current function > (gdb) cont > Continuing. > > Breakpoint 1, xf86SetCursor (pScreen=0x922ba58, pCurs=0x9653e38, x=7, y=409) > at ../../../../hw/xfree86/ramdac/xf86HWCurs.c:115 > 115 { > (gdb) break xf86HWCurs.c:123 > Breakpoint 2 at 0x8185b90: file > ../../../../hw/xfree86/ramdac/xf86HWCurs.c, line 123. > (gdb) cont > Continuing. > > Breakpoint 2, xf86SetCursor (pScreen=0x922ba58, pCurs=0x9653e38, x=7, y=409) > at ../../../../hw/xfree86/ramdac/xf86HWCurs.c:126 > 126 bits = dixLookupPrivate(&pCurs->devPrivates, > CursorScreenKey(pScreen)); > (gdb) n > 128 x -= infoPtr->pScrn->frameX0 + ScreenPriv->HotX; > (gdb) n > 126 bits = dixLookupPrivate(&pCurs->devPrivates, > CursorScreenKey(pScreen)); > (gdb) n > 128 x -= infoPtr->pScrn->frameX0 + ScreenPriv->HotX; > (gdb) n > 129 y -= infoPtr->pScrn->frameY0 + ScreenPriv->HotY; > (gdb) n > 132 if (!pCurs->bits->argb || !infoPtr->LoadCursorARGB) > (gdb) n > 139 if (!(infoPtr->Flags & HARDWARE_CURSOR_UPDATE_UNHIDDEN)) > (gdb) > 143 if (pCurs->bits->argb && infoPtr->LoadCursorARGB) > (gdb) > 144 (*infoPtr->LoadCursorARGB) (infoPtr->pScrn, pCurs); > (gdb) > 0xb5ffc0b0 in ?? () from /usr/lib/xorg/modules/drivers/nvidia_drv.so > > If anyone has pointers for what I should look at, let me know. I'll > try to read some sources later this week, I haven't had the time to do > that yet.
It's odd that GDB is getting confused when doing a "next" over the call through the function pointer. I'll bet it's because your X server is compiled with optimization, which also explains it jumping between lines 126 and 128 a few times. If you want to properly step through xf86SetCursor, you might be able to put a breakpoint on line 155, the last line of the function. You might also have better luck if you compile an X server without optimization. You could start by getting a backtrace to see who is calling xf86SetCursor. Also, just continuing from there and seeing if it's hitting the breakpoint repeatedly would be a good thing to try. -- Aaron _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
