Xpra: Ticket #1246: XStata-MP 14.0 crashes when running 'evince'

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



Tue, 05 Jul 2016 18:54:00 GMT - esarmien: attachment set

Xpra stata logs


Thu, 07 Jul 2016 07:52:21 GMT - Antoine Martin: owner, description changed

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.


Thu, 07 Jul 2016 13:31:49 GMT - 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


Thu, 07 Jul 2016 15:44:33 GMT - Antoine Martin: status changed; resolution set

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.


Tue, 12 Jul 2016 16:52:22 GMT - Antoine Martin: milestone changed

Milestone renamed


Sat, 23 Jan 2021 05:19:01 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1246