Bug 109585 - Remote X11 session fails - XQuartz crashes when forwarding ROOT graphics
Summary: Remote X11 session fails - XQuartz crashes when forwarding ROOT graphics
Status: RESOLVED MOVED
Alias: None
Product: XQuartz
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 2.7.11 (xserver-1.18.4)
Hardware: Other All
: high critical
Assignee: Vian
QA Contact: Jeremy Huddleston Sequoia
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-08 10:55 UTC by Anna
Modified: 2019-05-23 18:33 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Ngeod (3.09 KB, text/html)
2019-02-09 10:09 UTC, Vian
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anna 2019-02-08 10:55:22 UTC
Hi, 

I came here with an unusual issue as a last resort, but seemingly I'm not the only user with the same problem (see links below).

Reproducible crash of XQuartz happens under the following conditions:

- Remotely connecting (ssh -XY user@server) to a Linux server (Scientific Linux - Red Hat based - various kernel versions at CERN and PSI) from a Mac (OSX, both Sierra and latest Mojave) 

- try to launch ROOT with graphics (https://root.cern.ch/ , the latest root5, 5.34/38) which is our "work horse" application in particle physics

- when launching ROOT, connection establishes, credentials are ok, and an X window even flashes up for a (milli)second, then XQuartz is crashing with segmentation faults in the Apple crash report.
Verbose output, ssh -X -v (showing that all is OK until the crash) 

###########

debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 129.129.141.177 53580
debug1: x11_connect_display: $DISPLAY is launchd
debug1: channel 1: new [x11]
debug1: confirm x11
Socket accepted

Error in RootX11IOErrorHandler: fatal X11 error (connection to server lost?!)

**** Save data and exit application ****

###########

Now the really weird things:

- all other X window apps I tried can tunnel through well (including xeyes, emacs, firefox), so I posted this issue to the ROOT developers 
- BUT, it cannot be (only) a ROOT problem: a colleague with the SAME operation system and SAME XQuartz version on the SAME remote machine has no problem opening the same application.
- We compared our environments, I reinstalled XQuartz, etc. The only possible difference we found: I have Homebrew packages, he has Macports; e.g. he installed XQuartz via Macports, while I used the dmg file from the webpage.
- other weird stuff: this problem happened suddenly(!), first on my OSX Sierra (I used the same ROOT app on the same PC some months before). The only difference I can think of in this time:
  -- I got some new Homebrew packages,
  -- There were some usual security updates to Sierra
  
I thought first it might be some unresolvable security related issue with Sierra, so I upgraded to OSX Mojave for this reason, as my colleague had no issue there. But the problem persisted.

I went trough so many troubleshooting steps and nothing helped. Do you think I can try something besides the conventional things (reinstall XQuartz, try different versions)? 

Is it possible there is a problem between Homebrew installations and XQuartz, or any environment related issues with XQuartz? I want to keep my Homebrew stuff, it would be really painful to switch to Macports now.


see also:

https://root-forum.cern.ch/t/remote-x11-session-fails-xquartz-crashes-when-forwarding-root-graphics/32634

Also, similar problem appeared here:

Bug 103032
Comment 1 Vian 2019-02-09 10:09:21 UTC
Created attachment 143347 [details]
Ngeod

Dfdd
Comment 2 GitLab Migration User 2019-05-23 18:33:00 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/814.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.