OpenNX Client / Bugs / #80 OpenNX crashes on Mac OS X Yosemite

Morgan Hough - 2014-10-17

I reinstalled XQuartz and now the GUI opens and I am able to authenticate with the server but the actual desktop window doesn't open and you are dropped back to the connection window

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

davmp - 2014-10-19

The desktop window isn't opening because of a further issue in setting up the session...

This can be seen by modifying your server's node.conf to turn on a more verbose logging level (I used 6) and also keeping your session's files after it ends. I'm seeing the following in the 'session' log file within those saved files:

Info: Accepted connection from '127.0.0.1'.
Error: The remote NX proxy closed the connection.
Error: Failure negotiating the session in stage '7'.
Error: Aborting session with 'Unable to open display <....>

From research, this seems to imply the client-side isn't doing it's thing during stage 7. This next statement is a bit of a leap, but I believe the evidence is there for it. And that is, it appears the OpenNX client is dieing while trying to connect the session to the X11 display.

I found evidence that other X11 applications are having similar problems once the OS has been upgraded to Yosemite (10.10) and/or XQuartz has been upgraded to 2.7.7, It seems the common point these problems mention is the longer DISPLAY variable values that are now being setup. For example, mine is now:

/private/tmp/com.apple.launchd.aCIl2gjchL/org.macosforge.xquartz:0

Which is longer than 64 chars -- it's actualy 67 chars long I've seen other app's bug reports which indicate they weren't setup to handle more than 64 chars and were truncating that string during manipulation, so they couldn't actually connect to the display. Perhaps the problem with OpenNX is exactly the same thing?

If so, a small change to declare that handling of that value to be up to 128 chars or something larger should fix it.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Morgan Hough - 2014-10-20
  
  Hi davmp,
  
  Thanks for your report. Does the change need to be made on the XQuartz side? It seems like this would have shown up with other apps that use X11. Have you tried to report this to the XQuartz development team?
  
  Cheers,
  
  -Morgan
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - davmp - 2014-10-21
    
    Hello Morgan,
    
    From what I saw of other X11 app bug reports running under Yosemtie / new XQuartz, the issue has been fixed in the app side and not XQuartz. All the reports said XTerm, XEyes, etc worked and only their app had issues. They then identified the longer-than-64-char-length display string, modified their code and fixed their app. I say 'all' but I mean I only found two similar reports -- one was Inkscape and the other I'm drawing a blank on recalling now that it's a few days later.
    
    I don't personally believe XQuartz has any problems here, so no I didn't report anything to them. Perhaps I'm being unfair but the long DISPLAY strings are probably required for a good reason and they just expect apps to faithfully reproduce the string no matter how long it is. As far as I understand, there is no previous contract on what length they could be so it's kind of hard to say their new format and length is a bug.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Pavel Snopok - 2014-10-19

I followed the discussion in this forum:

https://answers.launchpad.net/inkscape/+question/249957

and ran the following commands:

Xnest :2 &> /dev/null &
DISPLAY=:2

After that, I ran

/Applications/OpenNX/OpenNX.app/Contents/MacOS/OpenNXapp

and it worked, I could connect to the remote machine.

So, it looks likely that the $DISPLAY variable is the culprit.

Last edit: Pavel Snopok 2014-10-19

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Morgan Hough - 2014-10-20
  
  Hi Pavel,
  
  I tried this and I am still unable to get a session window to open. I am still able to authenticate and select my suspended session but now the connection manager also quits and still no session window opens.
  
  Should Xnest be a black screen when you run it? Is there anything else I can check about my setup?
  
  Cheers,
  
  -Morgan
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - davmp - 2014-10-21
    
    Hi Morgan,
    
    Yes, Xnest starts up as just a big empty black screen.
    
    Note that the suffix after "Xnest" in the launching command line is the DISPLAY var. Once Xnest is up, make sure you export this as DISPLAY in the command prompt you're going to launch OpenNX from, and then manually run the OpenNX binary from that prompt. You can not just launch OpenNX from it's regular icon as then it will pickup the global DISPLAY name rather than your new one of ":2"
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- davmp - 2014-10-21
  
  This worked for me too! Xnest to the rescue as a way to redirect from a long DISPLAY name to a short one!
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

hachepunto - 2014-10-20

Just re-install XQuartz works great for me!
Thx!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Pavel Snopok - 2014-10-23
  
  Yes, it would be interesting to know which version of XQuartz you have. I've reinstalled both XQuartz and OpenNX and that did not help. What exactly did you do to "reinstall", in particular, what did you do to remove XQuartz prior to reinstalling? Thanks!
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - hachepunto - 2014-10-23
    
    Bad news. openNX now open but it can't connect. The console message:
    
    23/10/14 12:00:47.365 opennx[2660]: opennx(2660,0xa0f791d4) malloc: error for object 0xcf4f80: pointer being realloc'd was not allocated
    set a breakpoint in malloc_error_break to debug
    23/10/14 12:00:47.365 opennx[2660]: opennx(2660,0xa0f791d4) malloc: error for object 0xcf4f80: pointer being freed was not allocated
    set a breakpoint in malloc_error_break to debug
    
    XQuartz v 2.7.7 (xorg-server 1.15.2)
    
    regards
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

davmp - 2014-10-20

That doesn't work for me, nor I suspect the others who've replied here since we all said we've reinstalled and had problems. Or are you using something other than XQuartz 2.7.7?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- mckeuken - 2014-10-23
  
  Same problem here as damvmp; using latest X11, openNX. Xnest trick did not work.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

I noticed this in /var/log/system.log when OpenNX fails to restore the session (after auth and selecting a suspended session):

Oct 25 10:07:30 hostname org.macosforge.xquartz.startx[979]: /opt/X11/bin/xinit: XFree86_VT property unexpectedly has 0 items instead of 1
Oct 25 10:07:31 hostname opennx[977]: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.0 instead of 10.10.0. Use NSProcessInfo's operatingSystemVersion property to get correct system version number.
        Call location:
Oct 25 10:07:31 hostname opennx[977]: 0   CarbonCore                          0x901857e7 ___Gestalt_SystemVersion_block_invoke + 135
Oct 25 10:07:31 hostname opennx[977]: 1   libdispatch.dylib                   0x93c240b5 dispatch_once_f + 251
Oct 25 10:07:31 hostname opennx[977]: 2   libdispatch.dylib                   0x93c250d8 dispatch_once + 31
Oct 25 10:07:31 hostname opennx[977]: 3   CarbonCore                          0x90117fb8 _Gestalt_SystemVersion + 1050
Oct 25 10:07:31 hostname opennx[977]: 4   CarbonCore                          0x90117b69 Gestalt + 150
Oct 25 10:07:31 hostname opennx[977]: 5   opennx                              0x001ea2a2 _Z14UMAInitToolboxtb + 50
Oct 25 10:07:31 hostname opennx[977]: 6   opennx                              0x001efbec _ZN5wxApp10InitializeERiPPw + 44

Looks like another app had to change which APIs they used for Yosemite related to this error:

http://www.alfredforum.com/topic/4938-gestalt-select-warning-message-fixed-25-b296/

Nick Jones - 2014-10-25

FWIW, XQuartz 2.7.5 with OpenNX 0.16.0.729 will connect and display a desktop but without the titlebar and has to be closed using kill -9.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Pavel Snopok - 2014-10-27
  
  Are you sure the desktop has no title bar? Usually it is just hidden under OSX system bar at the top of the screen. Check here: http://xquartz.macosforge.org/trac/ticket/832
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Pavel Snopok - 2014-10-27

I can confirm that the combination of XQuartz 2.7.5 + OpenNX 0.16.0.729 works with a caveat that the desktop has no title bar (no matter what the "Displays have separate Spaces" flag in "Mission Control" settings is set to). I can run Ubuntu 14.04 XFCE, but if I have "Floating window" selected (which is what I used before) everything runs unbearably slow. However, if I select "New virtual desktop", everything works smoothly (minus the title bar).

Last edit: Pavel Snopok 2014-10-27

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Peter Lewis - 2014-10-29

Reinstalling XQuartz worked once for me. Not sure what changed, but it stopped and I have no idea how to fix that.

The XNest method partially worked, but had issues with key mapping.

I noted the session log files that it was having an issue connecting to the env DISPLAY of a socket file:

$ echo $DISPLAY
/private/tmp/com.apple.launchd.qEo9b1qk3h/org.macosforge.xquartz:0

From ~/.nx/S*/session:
...
Info: Proxy running in client mode with pid '47102'.
Session: Starting session at 'Wed Oct 29 17:11:55 2014'.
Error: Failed to resolve address of '/private/tmp/com.apple.launchd.qEo9b1qk3h /org.macosforge.xquartz'.
Error: Unknown display host '/private/tmp/com.apple.launchd.qEo9b1qk3h/org.macosforge.xquartz'.
Session: Session terminated at 'Wed Oct 29 17:11:55 2014'.

So I went a bit old school and set the display manually, then xhost +'d it. Not the most secure, but no one else should be logged into my box. I probably could have done xauth with the magic cookie stuff, but I didn't

Code (note that I use and install my own bash from brew, so path is different):
#!/usr/local/bin/bash
DISPLAY=:0
xhost +localhost
/Applications/OpenNX/OpenNX.app/Contents/MacOS/OpenNXapp

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Nick Jones - 2014-10-30
  
  The script at the end actually worked for me. I honestly didn't run it exactly but something similar:
  
  xhost +localhost DISPLAY=:0 /Applications/OpenNX/OpenNX.app/Contents/MacOS/OpenNXapp
  
  My keyboard bindings were very odd after connecting to a RHEL5.8 host, but after some searching I found a hack/fix that worked in this case. Change the .nxs file to this:
  
  <option key="Current keyboard" value="true"/>
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Peter Lewis - 2014-10-30

I've noted other X11 applications having similar issues.

http://root.cern.ch/phpBB3/viewtopic.php?f=3&t=18785

They recompiled against the new yosemite XCode libraries and that purportedly fixes things.

I can't get it to compile, but someone else may want to give it a shot.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Max Greenblatt - 2014-11-02

This doesn't fix anything, but if you are looking for a workaround and are using a NX 3.5 server, using NoMachine's mac client worked for me. https://www.nomachine.com/download

These instructions were helpful to me: https://www.nomachine.com/AR04J00627

Also, I needed to use xrandr to get the screen to a manageable size.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

David Jones - 2014-11-24

The only work around I have found is to download both OpenNX and NoMachine 4. Setup the connection using OpenNX and save a link to the connection on your desktop. Then open NoMachine and select "open" and navigate to the connection on the desktop created by OpenNX. This connection should then work within the NoMachine.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jiro Fujita - 2014-12-03

I was able to get OpenNX 0.16.725 to work on Yosemite with XQuartz 2.7.5. It works as expected, with title bar and everything. I don't claim this will work for everybody else, but worth a try…

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

davmp - 2014-12-03

Post awaiting moderation.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Andrew Schmidt - 2014-12-03

Just to follow-up on Jiro Fujita's comment, I was able to verify with OpenNX 0.16.725 and XQuarts 2.7.5 (on Yosemite) that I could launch and use OpenNX normally. I had to mess with some configuration settings because I had switched to use NoMachine briefly, but with a little persistence it is working. I verified this on 3 different Macs, all working great. Thanks Jiro!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

OpenNX crashes on Mac OS X Yosemite

Group

Searches

Help

#80 OpenNX crashes on Mac OS X Yosemite

Related

Discussion