Debugging Code with XGrab* Calls


Home » Support » Index of All Documentation » Wing IDE Reference Manual » Advanced Debugging Topics »

Under X11 (Linux/Unix), Wing does not attempt to break XGrabPointer or XGrabKey and similar resource grabs when your debug process pauses. This means that X may be unresponsive to the keyboard or mouse or both in some debugging cases.

Fixing the debugger to detect and ungrab resources in this case is quite difficult and prone to confusing and unwanted behaviors. Here are some tips for working around this problem:

(1) Some toolkits have an option to disable resource grabs specifically to avoid this problem during debugging. For example, PyQt has a command line option -nograb that prevents it from ever grabbing the keyboard or pointer. Adding this to the debug process command line solves the problem.

If you are writing your own calls to XGrab* or similar functions, consider adding a mode where these calls are skipped.

One trick that often helps is to move processing from the callback where the pointer or keyboard grab is still in effect into an asyncronous call-back that occurs at idle time. For example, under GTK use gtk_idle_add() and in wxPython try a wxTimer.

(2) Under XFree 4.2 and later, there is a configuration option you can set so that Ctrl-Alt-Keypad-/ will break through any active pointer and keyboard grabs:

# Let user break server grabs with ctrl-alt-keypad-/
Option "AllowDeactivateGrabs" "true"

This goes into your XF86Config file in the "ServerOptions" section. Check man XF86Config for the search path that X uses to find the config file and find the one that's used on your system. For example, on Mandrake 8.2 the config file is /etc/X11/XF86Config-4.

You will need to restart your X server for the config changes to take effect (for example, log out and back in again). Be aware that altering your XF86Config file can cause X to fail to start up. If this happens, you will need to fix it in text mode. If you get into this situation, typing startx after each edit is a good way to check whether your fix works.

If you need to check what version of XFree you're running, typing rpm -q XFree86 usually works or man XFree86 shows the version number at the very end of the man page.

(3) On Linux, if all else fails, you can use Ctrl-Alt-F1 through Ctrl-Alt-F6 on most distributions to get at six text-only virtual console. From there you can ps to find the debug process and kill it with kill -TERM or kill -9 if necessary. This will unlock your X windows display, which you can return to with Ctrl-Alt-F7.

(4) Displaying your debug process to another screen avoids tying up Wing in this way. Most servers will unlock the screen once you kill the debug process from Wing.

« 13.5. Debugging Extension Modules on Linux/UnixTable of Contents13.7. Debugging Non-Python Mainloops »