Bug 542973 - X server deadlock on Xt/motif application
X server deadlock on Xt/motif application
Status: CLOSED DUPLICATE of bug 543647
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Jackson
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-01 06:06 EST by Davide Cesari
Modified: 2010-02-16 05:05 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-16 05:05:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
gdb session after ctrl-c when application is runnning in Xnest (754 bytes, text/plain)
2009-12-01 06:06 EST, Davide Cesari
no flags Details
Screenshot of the working application on Fedora 8 (13.87 KB, image/png)
2009-12-01 06:12 EST, Davide Cesari
no flags Details
x11-xorg log file (84.21 KB, text/plain)
2009-12-03 04:37 EST, Davide Cesari
no flags Details
system /var/log/dmesg file (29.38 KB, text/plain)
2009-12-03 04:38 EST, Davide Cesari
no flags Details

  None (edit)
Description Davide Cesari 2009-12-01 06:06:56 EST
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.
Comment 1 Davide Cesari 2009-12-01 06:12:29 EST
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.
Comment 2 Davide Cesari 2009-12-01 09:57:43 EST
"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.
Comment 3 Chris Campbell 2009-12-02 11:55:47 EST
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
Comment 4 Davide Cesari 2009-12-03 04:37:19 EST
Created attachment 375714 [details]
x11-xorg log file
Comment 5 Davide Cesari 2009-12-03 04:38:31 EST
Created attachment 375715 [details]
system /var/log/dmesg file
Comment 6 Davide Cesari 2009-12-03 04:49:35 EST
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
Comment 7 Chris Campbell 2009-12-03 10:29:43 EST
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
Comment 8 Davide Cesari 2010-02-08 10:03:27 EST
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
Comment 9 Jean-Jacques Sarton 2010-02-10 02:37:26 EST
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.
Comment 10 Jean-Jacques Sarton 2010-02-10 02:56:57 EST
If nedit or ddd are launched with the parameter -sync the applications seem to work well.
Comment 11 Davide Cesari 2010-02-10 03:33:42 EST
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.
Comment 12 Davide Cesari 2010-02-11 11:08:22 EST
After some tests it seems that -sync does not have a positive effect.
Comment 13 Davide Cesari 2010-02-16 05:05:21 EST
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 ***

Note You need to log in before you can comment on or make changes to this bug.