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)? Thanks, ~David _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
