xpra icon
Bug tracker and wiki

Opened 14 months ago

Closed 14 months ago

Last modified 14 months ago

#1661 closed defect (invalid)

Xpra always gets stuck when working with Mono/Wine applications like Analysis HFSS, Fluid flow and etc

Reported by: spxu Owned by: spxu
Priority: major Milestone: 2.2
Component: core Version: trunk
Keywords: Cc: sipingxu@…

Description

Server OS: CentOS 6.8
Client OS: Windows 7

Reproduce steps:

  1. Start xpra session, i.e.

xpra start :100

  1. Start application, i.e.

export DISPLAY=:154
/apps/AnsysEM/AnsysEM17.0/Linux64/ansysedt

  1. Attach to the session
  1. The window shows up. Click on the title bar of the application or Drag the resize handler (at the bottom right of the window). The client disconnects. The whole session gets stuck until kill the application.

Attachments (2)

hfss.png (323.4 KB) - added by spxu 14 months ago.
hfss2.png (289.4 KB) - added by spxu 14 months ago.
screenshot of session got stuck

Download all attachments as: .zip

Change History (14)

comment:1 Changed 14 months ago by Antoine Martin

Owner: changed from Antoine Martin to spxu

Please use the recommended way for starting your application:

xpra start --start=/apps/AnsysEM/AnsysEM17.0/Linux64/ansysedt

And it should work fine.

Changed 14 months ago by spxu

Attachment: hfss.png added

Changed 14 months ago by spxu

Attachment: hfss2.png added

screenshot of session got stuck

comment:2 Changed 14 months ago by spxu

Cc: sipingxu@… added
Component: androidcore

comment:3 Changed 14 months ago by Antoine Martin

Resolution: invalid
Status: newclosed

See comment:1

comment:4 Changed 14 months ago by spxu

2017-10-16 13:20:21,548 DEBUG XShmWrapper.setup() XShmAttach(..) True
2017-10-16 13:20:21,548 DEBUG get(override-redirect, False) using get_property=True
2017-10-16 13:20:21,548 DEBUG get_transient_for window=WindowModel(0xa000aa), transient_for=None
2017-10-16 13:20:21,548 DEBUG get_wm_state(fullscreen) state_names=('_NET_WM_STATE_FULLSCREEN',)
2017-10-16 13:20:21,548 DEBUG get_wm_state(focused) state_names=('_NET_WM_STATE_FOCUSED',)
2017-10-16 13:20:21,549 DEBUG get_wm_state(maximized) state_names=('_NET_WM_STATE_MAXIMIZED_VERT', '_NET_WM_STATE_MAXIMIZED_HORZ')
2017-10-16 13:20:21,549 DEBUG get_wm_state(above) state_names=('_NET_WM_STATE_ABOVE',)
2017-10-16 13:20:21,549 DEBUG get_wm_state(below) state_names=('_NET_WM_STATE_BELOW',)
2017-10-16 13:20:21,549 DEBUG get_wm_state(shaded) state_names=('_NET_WM_STATE_SHADED',)
2017-10-16 13:20:21,549 DEBUG get_wm_state(skip-taskbar) state_names=('_NET_WM_STATE_SKIP_TASKBAR',)
2017-10-16 13:20:21,549 DEBUG get_wm_state(skip-pager) state_names=('_NET_WM_STATE_SKIP_PAGER',)
2017-10-16 13:20:21,549 DEBUG get_wm_state(sticky) state_names=('_NET_WM_STATE_STICKY',)
2017-10-16 13:20:21,549 DEBUG get_wm_state(modal) state_names=('_NET_WM_STATE_MODAL',)
2017-10-16 13:20:21,549 DEBUG get(override-redirect, False) returning default value=False
2017-10-16 13:20:21,550 DEBUG get(tray, False) returning default value=False

Gdk-ERROR **: The program 'Xpra' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 1930 error_code 3 request_code 3 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
aborting...
./start-xpra.sh: line 12: 15512 Aborted                 /usr/bin/xpra start :154 --bind-tcp=0.0.0.0:10054 -d "all" --auth=file --password-file="/home/spxu/xpra-test/xpra-auth" --daemon=no --start=/apps/AnsysEM/AnsysEM17.0/Linux64/ansysedt
Last edited 14 months ago by spxu (previous) (diff)

comment:5 Changed 14 months ago by spxu

Resolution: invalid
Status: closedreopened

Use xpra start --start=/apps/AnsysEM/AnsysEM17.0/Linux64/ansysedt does not work neither.

When I use client to attach, it server crashes, with error as appended above

comment:6 Changed 14 months ago by Antoine Martin

Please attach a longer debug log output sample to the ticket, not just the last few dozen lines.
You can try wiki/Debugging to get a meaningful backtrace.

If that doesn't reveal anything, then I am afraid that I would need to play with the application myself to debug it. Ansys is notoriously flaky.

comment:7 Changed 14 months ago by spxu

Resolution: invalid
Status: reopenedclosed

Previously I start the application without some environment variables of the HFSS. After I correct the starting script, it works.

comment:8 Changed 14 months ago by spxu

Resolution: invalid
Status: closedreopened

Hi Antoine,

I have a special case that hosts run HFSS cannot be reached by client. So, I have to start a xpra session on host2 with Xorg listening on, and start HFSS on host1 with remote DISPLAY, i.e. host2:100.

For this case, other applications work well, but not for HFSS, because the HFSS has to be started as child process of xpra. Is it possible to make this case work for HFSS?

Any suggestion will be highly appreciated. Thanks.

Last edited 14 months ago by spxu (previous) (diff)

comment:9 Changed 14 months ago by Antoine Martin

You can try setting the environment variables yourself, see:

xpra showconfig | grep start-env

FYI: using DISPLAY=host:no is very slow, even over a superfast LAN, as xpra uses synchronous X11 calls, etc. Avoid doing that.

comment:10 Changed 14 months ago by spxu

Sorry that I missled you. Use DISPLAY=host:no for Ansys HFSS can make the remote window show in the xpra session. But the problem is when I click the title bar or drag the resize handler, the xpra session got stuck.

comment:11 Changed 14 months ago by Antoine Martin

Resolution: invalid
Status: reopenedclosed

I understood what you said, the reply remains the same: don't run xpra on a different host from your application. (in your example: "host2" implies a different host, otherwise you could just use DISPLAY=:number

As for the hang you are seeing, see the env variables I pointed you to.

comment:12 Changed 14 months ago by spxu

I got your point. After I set the following environment variables, it works!

export UBUNTU_MENUPROXY=
export QT_X11_NO_NATIVE_MENUBAR=1
export MWNOCAPTURE=true
export MWNO_RIT=true
export MWWM=allwm
export GDK_BACKEND=x11

The Xpra is fantastic and tons of thanks.

Note: See TracTickets for help on using tickets.