People running legacy scientific applications with xview are running into a problem with the Xorg distributed with Fedora 11 and Ubuntu 9.0.4. Moving the mouse cursor over the window (or clicking/moving the windows) is fine. Clicking on a button causes the application (and all of X other than mouse movement) to freeze. Killing the application in single user mode and switching back to X is successful in my case. See: http://www.physionet.org/physiotools/xview/ I have been able to trace it down to a call using diagonstic fprintf()'s and strace to the glibc __select() function in xview-3.2p1.4/lib/libxview/notify/linux_select.c (see the above url for the base fc8 SPRM; I have a couple of other patches and modifications to the .spec file to get it to compile on fc11...after the modifications, I get the same behavior as reported by many other users). A typical __select() call that works (during mouse movements) appears to be identical to ones that fail. For example: About to run __select timeout pointer=(nil) width=1024 readfds=0xbfc34484 writefds=0xbfc34404 exceptfds=0xbfc34384 Finished with __select ret=1 Succeeds, but a mouse click: About to run __select timeout pointer=(nil) width=1024 readfds=0xbfc34484 writefds=0xbfc34404 exceptfds=0xbfc34384 Killed I recognize that calling select with a null struct timeval can cause indefinite delays for the application, but I'm surprised it freezes all of X. I'm guessing that either xview is uncovering an Xorg bug or an Xorg change is revealing an ancient xview bug. I've seen a bit of this on the internet, but I've been unable to find a bugzilla report to xorg directly, hence I'm reporting this. In case this might be helpful, I found the following comment on the internet about a race in xview select on SunOS: http://www.mombu.com/programming/programming/t-malloc-crash-solaris-26-signal-handler-1660273.html If I'm using threads and have to take async signals, I use the sigwait interface. If I'm using poll or select, I'll go with having the signal handler write the information about the signal on a pipe, and have it wake up the select or poll.... I used this many years ago to fix Xview which had an inherent race in the signal handling code since it couldn't check the flags and go to sleep atomically in select. (See pselect in Solaris 10).
Additional information and a workaround have come to light that hopefully will provide some information. Apparently issuing the command line option -Wfsdb, which tells the xview library to disable full-screen grabs prevents xorg from freezing and allows the mouse click to be passed to the program. See: http://www.physionet.org/physiotools/xview/ This apparently mirrors an ancient bug observed with an old IRIX version that has the same workaround: http://rainbow.ldeo.columbia.edu/documentation/sgi-faq/graphics/73.html Again, I am unclear if the Xwindow freezing is due to the a new xorg bug or an ancient xview bug, but it seems to me that at the least XWindows shouldn't freeze because of a single misbehaving application.
I have chased down the code that is disabled with -Wfsdb. -Wfsdb sets the variable fullscreendebug to 1. If I remove the check for this variable in libxview/window/window_set.c in the functions window_grab_selectbutton() and window_release_selectbutton(), this command line option no longer prevents the XOrg/application freeze. I am not enough of a XWindows programmer to identify what might be going wrong with this code that causes the hang in the select() call described in previous comments. The code that -Wfsdb skips over in window_grab_selectbutton() is in the following snippet: if ((newmask & FocusChangeMask) && (kbd_use) && (!fullscreendebug)) { newxmask = newmask; grab_button_mask = ButtonPressMask | ButtonReleaseMask | (newxmask & EnterWindowMask) | (newxmask & LeaveWindowMask); if (newxmask & ButtonMotionMask) grab_button_mask |= Button1MotionMask; XGrabButton(xv_display(info), Button1, None, xv_xid(info), FALSE, grab_button_mask, GrabModeSync, GrabModeSync, None, None); } else if (oldmask & FocusChangeMask) XUngrabButton(xv_display(info), Button1, None, xv_xid(info)); The code that -Wfsdb skips over in window_release_selectbutton() is: if (event_action(event) == ACTION_SELECT && event_is_down(event) && (win->xmask & FocusChangeMask) && (!fullscreendebug)) { Xv_Drawable_info *info; DRAWABLE_INFO_MACRO(window, info); XAllowEvents(xv_display(info), AsyncBoth, CurrentTime); XFlush(xv_display(info)); } This information could be used to patch XView, but I include these details in case this code will help debug the XOrg freeze.
Is the server locking up or is the xview application just not responding? "Xorg freeze" isn't quite explaining what symptoms you're seeing...
(In reply to comment #4) > Is the server locking up or is the xview application just not responding? > "Xorg freeze" isn't quite explaining what symptoms you're seeing... From the original report: "Moving the mouse cursor over the window (or clicking/moving the windows) is fine. Clicking on a button causes the application (and all of X other than mouse movement) to freeze. Killing the application in single user mode and switching back to X is successful in my case." To restate: Once the button was clicked, all that one could do was move the mouse cursor, arguing that the machine wasn't totally locked up. Nothing, including the window manager and all other X applications, responded to any clicks, etc. This behavior clearly did not just apply to the xview application. Killing the misbehaving application (by switching out of X into single user mode) and then returning to X restored the behavior of the rest of the window manager and other X applications. This said, I have since migrated to later versions of Fedora with later versions of Xorg (whatever was released with Fedora 12--I've not been able to match the version numbers I can find on my systems with anything resembling the version numbers here) and this problem is no longer present.
Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.