#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:
- Start xpra session, i.e.
xpra start :100
- Start application, i.e.
export DISPLAY=:154
/apps/AnsysEM/AnsysEM17.0/Linux64/ansysedt
- Attach to the session
- 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)
Change History (15)
comment:1 Changed 3 years ago by
Owner: | changed from Antoine Martin to spxu |
---|
Changed 3 years ago by
comment:2 Changed 3 years ago by
Cc: | sipingxu@… added |
---|---|
Component: | android → core |
comment:4 Changed 3 years ago by
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
comment:5 Changed 3 years ago by
Resolution: | invalid |
---|---|
Status: | closed → reopened |
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 3 years ago by
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 3 years ago by
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
Previously I start the application without some environment variables of the HFSS. After I correct the starting script, it works.
comment:8 Changed 3 years ago by
Resolution: | invalid |
---|---|
Status: | closed → reopened |
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 appreicated.
Thanks,
Siping
comment:9 Changed 3 years ago by
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 3 years ago by
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 3 years ago by
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
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 3 years ago by
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.
comment:13 Changed 5 days ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1661
Please use the recommended way for starting your application:
And it should work fine.