Created attachment 375026 [details] gdb session after ctrl-c when application is runnning in Xnest Description of problem: I have a motif application which puts the X server in a deadlock situation when opening a drop-down menu(? is it the correct term? - a local menu which appears by right clicking the mouse on a motif widget within the application window). Other kind of menus (e.g. from menubar or menu opening subwindows) work correctly. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.7.1-7.fc12.x86_64 lesstif-0.95.2-1.fc12.x86_64 openmotif-2.3.2-5.fc12.i686 libXt-1.0.7-1.fc12.i686 and corresponding devel/debuginfo packages. Unfortunately the motif application is a closed-source complex client-server application (xcdp/sms process scheduler from ecmwf.int) and the bug only appears after connection to a server, so it is hard to provide a test case; if you can point me to some motif application packaged with Fedora I could look for a similar bug in them. How reproducible: Always reproducible Steps to Reproduce: 1.start the graphical application 2.right click a motif widget in order to open a drop-down menu Actual results: The X server goes into an infinite loop, mouse pointer is confined within application window, no reaction to keyboard events except Alt-Ctrl-F? & Co., I can only switch to console and kill the X application, then the X session resumes smoothly. Expected results: A drop-down menu should open below the mouse cursor. Additional info: The bug shows up on F12 X server, even running remotely the client X application compiled under a previous Fedora version; conversely the application compiled on F12 runs correctly on a remote F11 or F8 X display, meaning that the problem is related to X, not to lesstif/openmotif/Xt libraries. The bug appears also running in a Xnest window with no window manager. Debugging by running in Xnest shows that the application is polling the X server socket for events when the X server deadlocks.
Created attachment 375028 [details] Screenshot of the working application on Fedora 8 The screenshot shows the application correctly working on Fedora 8: right clicking on "getgme" widget opens the menu "task /lm..." up to "script..." on F12 the menu does not show up and the X server deadlocks, the X cursor changes shape as if the menu was opened.
"Good" news: I can replicate the bug with a precompiled Fedora package: ddd the graphical interface to gdb debugger. I suggest to run into Xnest in order not to lock the X server, but that step is not necessary, of course: Steps to Reproduce: 1. Xnest -pn :1& 2. metacity --display :1& # or mwm or no window manager, not really necessary, just to be sure the wm is not responsible 3. ddd -display :1 # start the debugger with no debugged program, then close the "tip of the day" window 4. right-click in the empty space at the center of the ddd window (where the source code should be) - a temporary window will appear ("Print", "Display" ..., "Clear at") with all options greyed out 5. right-click again somewhere in the big empty space outside the just-appeared temporary window at this point you cannot get rid of the temporary window or do any other operation on the screen until ddd is killed; with Fedora 8 this does not happen.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf, if available), /var/log/dmesg, and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thanks in advance. Davide, the above is a 'canned' response we've been asked to ask for all xorg issues. Please attach the logs if you have them. I am also assigning this to one of the developers, and cc:ing another and they can let you know what else they might need. (or let me know). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 375714 [details] x11-xorg log file
Created attachment 375715 [details] system /var/log/dmesg file
There is no /etc/X11/xorg.conf file, I guess configuration is generated on-the-fly. Anyway the problem seems not to be related to hardware/driver issues, since it shows up also in a software xnest, as well as on a i686 installation with an ATI Radeon graphics card (vs. x86_64 with Nvidia). Do not hesitate to ask me other information or to do other tests, thank you for your interest and for your work, Davide
All logs aboard, assigned to ajax, cc:d to airlied, setting triaged keyword, setting status to ASSIGNED (Fedora 12) This bug has been triaged -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Any new? A recent update of the X server package on Fedora 12 repository did not give any improvement :-( Name : xorg-x11-server-Xorg Relocations: (not relocatable) Version : 1.7.4 Vendor: Fedora Project Release : 1.fc12 Build Date: ven 08 gen 2010 05:31:56 CET Install Date: mar 19 gen 2010 16:55:30 CET Build Host: x86-01.phx2.fedoraproject.org
The problem occur also with nedit or ddd runnning localy (no XNest and so on). On my system, there is from time to time a lock of the desktop, lesstif/motif client are not involved for this case. The only solution is then to kill the server.
If nedit or ddd are launched with the parameter -sync the applications seem to work well.
Sure, Xnest is not necessary, the use of Xnest was just to avoid exiting to console and kill application, and to show it is independent of the video driver. Thanks for the suggestion of -sync, it can be a temporary patch and a hint for the bug trackers.
After some tests it seems that -sync does not have a positive effect.
I found this is a duplicate of bug 543647, posted 1 day later, https://bugzilla.redhat.com/show_bug.cgi?id=543647 which received more attention. It seems to be solved in testing. *** This bug has been marked as a duplicate of bug 543647 ***