GNOME Bugzilla – Bug 331577
session/mouse hang while using GOK
Last modified: 2006-11-26 00:16:02 UTC
Forwarded from: https://launchpad.net/distros/ubuntu/+source/gok/+bug/31507 When GOK is running, a click on a gnome-panel icon causes the interface hang, requiring the X session to be killed. Clicking on an icon on the desktop representing the same application (like gedit) does not cause the problem, nor does starting an application from the menu. Running GOK from the command line, followed by a click on the panel icon does not produce any error messages. Any log files I should check? The accessibility infrastructure seems to otherwise work fine with gnopernicus.
Thanks for the report. Some initial questions: 1. What version of GOK? 2. How was GOK launched in the case where there is a hang? 3. Is GOK docked or floating? 4. Is this behaviour consistently reproducible in the case you have described?
Hi, Thanks for helping. * GOK version 1.0.6 in floating mode * It doesn't seem to matter how it was started. Launching as Gnome starts up, from the Applications menu or from the command line produces the same result. HOWEVER, you'll probably find the command line output useful (sorry, I should have included this with the initial report): ---------------- GTK Accessibility Module initialized Bonobo accessibility support initialized /dev/js0: No such file or directory 0 event types available login mode = false Word prediction dictionary contains a total of 3000 words ** (gok:25841): WARNING **: No extension devices or no corepointer device found. (gok:25841): Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed ** Message: corepointer detached... ------------------ ... I guess we have made some changes to how we handle mouse devs for dapper? It is consistent. After starting GOK I can launch applications from the menu or dektop icons, but whe I click a toolbar icon it freezes (the depressed icon does not even pop back up). There is a blue line (1px) along the top of the screen and a green one along the left hand side after the crash. The mouse still moves but doesn't respond to clicks. StickyKeys still works because I can press Ctrl-Alt-Backspace one key at a time to kill X.
Thanks. Do you have access to "at-poke" (http://cvs.gnome.org/viewcvs/at-poke/)? This is another tool that can activate things using the same API (at-spi) that GOK uses. Knowing the behavior at-poke causes would help triage this bug. In general at-poke can be a very handy tool for diagnosing accessibility issues so I think it is worth getting to know (if you don't already).
Henrik, I uploaded a recent at-poke (Dapper) version to archive, but it will sit a while in NEW, I fear. Until then, could you try http://people.ubuntu.com/~dholbach/at-poke/ ?
Thanks for the fast packaging Daniel :) OK, that's interesting. This is my second attempt at writing this bug report since my system crashed last time (I was running at-poke at the time). When I tried starting at-poke I got this message: ** (at-poke:6525): WARNING **: initial 'DISPLAY=:0.0' target '(null)' But the interface didn't come up this time. Ctrl+C and try again. The second time I start it I do get a window and this slightly different message: ** (at-poke:7520): WARNING **: initial 'DISPLAY=:0.0' target '(null)' I also get this message: ** (at-poke:7520): CRITICAL **: get_accessible_at_index: assertion `ret' failed Poking different applications like gedit and gnome-terminal works fine. Poking at gnome-panel also works fine. I can even start applications from the panel, which is what caused the crash originally. Then finally when I exit at-poke the desktop crashes again ... I hope that helps. Let me know if I should do more poking.
This is the part of the above output which seems to be of interest: >** (gok:25841): WARNING **: No extension devices or no corepointer device >found. >(gok:25841): Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET >(widget)' failed >** Message: corepointer detached... This message is indicating that something's wrong or at least highly unexpected about your input device configuration. Could you please attach your X server configuration file? It probably is in one of the following places (please send the one at the "first" location in the following list, if you happen to have more than one): [ignore the ones with $XORGCONFIG if that env variable is not defined on your system] /etc/X11/$XORGCONFIG /usr/X11R6/etc/X11/$XORGCONFIG /etc/X11/xorg.conf-4 /etc/X11/xorg.conf /etc/xorg.conf /usr/X11R6/etc/X11/xorg.conf.<hostname> /usr/X11R6/etc/X11/xorg.conf-4 /usr/X11R6/etc/X11/xorg.conf /usr/X11R6/lib/X11/xorg.conf.<hostname> /usr/X11R6/lib/X11/xorg.conf-4 /usr/X11R6/lib/X11/xorg.conf
Created attachment 59763 [details] xorg.conf file
Right, I've attached my xorg.conf file. Hope that helps.
Henrik and David: From code inspection of this codepath it seems that gok isn't actually detaching the core pointer; thus, the problem isn't that gok's directly interfering with the pointer. The odd warning means, in this case, that you have no XInput extension devices configured. (Gok really really wants/needs XInput devices but will do its best in their absence to work, and is not expected to cause a hang or similar interference in their absence). So what's really happening here? I strongly suspect that GOK isn't really the culprit; more likely at-spi-registryd is hanging or crashing during some GOK interaction, or possibly GOK itself is dying and in so doing is hanging at-spi-registryd. To determine that, we need to do some strace/tops checking to see what at-spi-registryd are doing when the problem occurs, to see if the at-spi registry is still alive, etc. If this doesn't help uncover the problem, then reconfiguring your system to add a non-corepointer XInput device (see Appendix of Gnome Accessibility Guide, it's a bit messy to do) and configuring GOK to use that may free things up. As I said, I strongly suspect that GOK isn't directly responsible at all, but is tickling something nasty elsewhere, or perhaps GOK is dying in such a way that at-spi-registryd gets stuck. A hung AT can mess up your desktop pretty thoroughly.
Thanks Bill. I still find the intial report, that this is a fairly specific case where this happening, to be very puzzling. Henrik, I agree with Bill... getting some debugging info would be very helpful. -- even if you could ssh into your hung machine and look at the processes (ps -x) and perhaps run top to see what the loads are it would be a start.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Closing as obsolete. Please reopen if this is not the case.