xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#1246 closed defect (invalid)

XStata-MP 14.0 crashes when running 'evince'

Reported by: esarmien Owned by: esarmien
Priority: major Milestone: 1.0
Component: client Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

Hi,

I am currently running the latest stable XPRA 0.17.4.

Our users running xstata-mp through XPRA have been reporting spontaneous crashes, which I can confirm due to core-dumps produced both by XPRA and X-Stata. At first, I thought this was an XStata problem, given that Stata is notoriously buggy, however --

When I launch XStata-MP through XPRA and click the 'Help' button, Evince opens a PDF file and Xpra and Stata immediately crashes. This is not reproducible when running Xstata directly.

I can remedy this problem by running gnome-settings-daemon and then running xstata-mp as follows

--start-child="gnome-settings-daemon; xstata-mp"

but I am not sure if that's really a viable or desirable solution.

Here is all the bug info.

┌─[esarmien@dev-rce6-1.hmdc.harvard.edu] 
└─[~]> uname -a
Linux dev-rce6-1.hmdc.harvard.edu 2.6.32-642.1.1.el6.centos.plus.x86_64 #1 SMP Wed Jun 1 03:11:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
─[esarmien@dev-rce6-1.hmdc.harvard.edu] 
└─[~]> xpra --version
xpra v0.17.4
┌─[esarmien@dev-rce6-1.hmdc.harvard.edu] 
└─[~]> python --version
Python 2.6.6

Below I am attaching the output of the debug log in a zip file.

# This is the configuration file for Xpra
# MANAGED BY PUPPET. DO NOT EDIT MANUALLY.


auto-refresh-delay = 0.15

clipboard = auto

compression_level = 0

compressors = lz4, zlib, lzo

csc-modules = all

dbus-proxy = yes

displayfd = yes

encodings = all

input-method = none

keyboard-sync = yes

log-file = $DISPLAY.log

mdns = no

min-quality = 30

min-speed = 70

mmap = yes

mmap-group = no

notifications = yes

opengl = no

packet-encoders = rencode, bencode, yaml

pings = no

pulseaudio = no

pulseaudio-command = pulseaudio --start --daemonize=false --system=false \
                --exit-idle-time=-1 -n --load=module-suspend-on-idle \
                --load=module-null-sink \
                --load=module-native-protocol-unix \
                --log-level=2 --log-target=stderr

quality = auto

sharing = no

speaker = no

speed = auto

system-tray = yes

title = @title@ on @client-machine@

video-decoders = all

video-encoders = x264,vpx

wm-name = Xpra

xvfb = xpra_Xdummy -noreset -nolisten tcp +extension GLX \
                +extension RANDR +extension RENDER \
                -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log \
                -config /etc/xpra/xorg.conf
$ xpra -d all --daemon=no start --exit-with-children --start-child="/usr/bin/pexpect_run.py xstata-out.txt /nfs/tools/apps/stata/14/xstata-mp" 2>&1> ~/xstata-mp-xpra-debug.txt

$ xpra --daemon=no -d all attach :0 &>~/xstata-mp-xpra-attach.txt

Attachments (1)

xstata-14-xpra-fail.zip (387.7 KB) - added by esarmien 4 years ago.
Xpra stata logs

Download all attachments as: .zip

Change History (5)

Changed 4 years ago by esarmien

Attachment: xstata-14-xpra-fail.zip added

Xpra stata logs

comment:1 Changed 4 years ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to esarmien

Are you sure that xpra crashed?
You server log shows:

2016-07-05 14:51:54,236 child '/usr/bin/pexpect_run.py xstata-out.txt /nfs/tools/apps/stata/14/xstata-mp' with pid 14531 has terminated
...
2016-07-05 14:51:54,236 all children have exited and --exit-with-children was specified, exiting

That's shortly after evince shows up:

2016-07-05 14:51:53,827 Discovered new ordinary window: WindowModel(0xa00003) (geometry=(259, 54, 600, 600))
...
2016-07-05 14:51:53,828 make_metadata(4, WindowModel(0xa00003), class-instance)={'class-instance': ['evince', 'Evince']}

This doesn't look like an xpra bug, and I am unable to run this proprietary software on my system.
Please try running xstata in an xterm window to see if it exits or not.
Maybe pexpect isn't helping.
If it does crash... maybe you can try to attach gdb to see where the problem is.

comment:2 Changed 4 years ago by esarmien

Antoine,

You are right. This does entirely seem to be because of 'pexpect.' Sorry for the hastily created ticket.

I use pexpect because XStata-MP detaches itself on start, so, XPRA thinks Xstata-MP has exited. If I do not use --exit-with-children, I can use Xstata-mp, but, if I quit XStata-MP, XPRA doesn't quit on the server side, which I would like to happen.

Have any tips on how I can accomplish this?

See the process listing

esarmien 17027 31954 36 09:28 pts/1    00:01:12 /usr/bin/python2 /usr/bin/xpra --daemon=no start --start-child=/nfs/tools/apps/stata/14/xstata-mp
esarmien 17068     1  0 09:28 pts/1    00:00:00 /nfs/tools/apps/stata/14/xstata-mp
esarmien 17117  2435 50 09:28 pts/5    00:01:28 /usr/bin/python2 /usr/bin/xpra --daemon=no -d all attach :0

xstata-mp is not a child of the xpra process.

Thanks
Evan

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 4 years ago by Antoine Martin

Resolution: invalid
Status: newclosed

There is no easy way to monitor a process that daemonizes itself (parent pid=1) from userspace.
Usually, daemons provide their pid somewhere or have the ability to run non-daemonized. Maybe xstrata has such a feature?
If not, your best bet would be to write a script that matches the process from the process list, then polls it until it terminates. You can make that more robust if you can provide unique command line arguments to xstrata-mp that you can then match in the process list. Again, no idea if xstrata will let you do this.

Closing as this is not an xpra bug.

comment:4 Changed 4 years ago by Antoine Martin

Milestone: 0.181.0

Milestone renamed

Note: See TracTickets for help on using tickets.