bugGNU Octave - Bugs: bug #44174, Remote X-Window display: command...

 
 

bug #44174: Remote X-Window display: command window blank, all other windows fine

Submitted by:  Michael C. Grant <mcgrant>
Submitted on:  Tue 03 Feb 2015 04:16:41 PM UTC  
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Michael Grant Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Fri 09 Sep 2016 04:42:47 PM UTC, comment #20: 

UBUNTU 14.04/16.04 resolution

I too had been having this octave command window problem using both Ubuntu 14.04 and 16.04: Octave works fine when launched from the console, but remotely using Putty (with X forwarding) or ssh -X, the command window is blank. 

I was able to resolve the problem comparing the shell environments (printenv) from my ssh -X session (resulting in octave command window blank), and that from my console (octave command window visible).

The minimal environmental change that I required to get octave to function under ssh -X (or Putty with X forwarding) on a Ubuntu 14.04 or 16.04 system are below.  These changes may be added to the configuration script .bashrc, but their impact on other X applications has not been evaluated.

export GTK_MODULES=gail:atk-bridge:unity-gtk-module
export GNOME_DESKTOP_SESSION_ID=this-is-depricated

-William

William Deninger <wdeninger>
Sat 11 Jun 2016 10:24:03 PM UTC, comment #19: 

Michael, I think I may have found a workaround:

I had a similar experience this week after upgrading from Fedora 19 to Fedora 23 and also re-compiling Octave.

The gui window will open, but as soon as I try to run anything that opens a figure() window, everything hangs and  the octave gui goes blank and unresponsive.

After much trouble I found out that the problem was related to the ssh X11Forwarding mechanism, which I was using for the login into the machine where I started octave (which was actually localhost, but I was using ssh -X anyway).

Workaround: If I invoke octave with

env DISPLAY=:0 octave

rather than allowing it to run with the DISPLAY=localhost:11 tunnel that ssh -X creates, then the problem goes away.

I have not been able to find what was wrong with /etc/ssh/ssh_conf. I tried multiple variations (yes/no) of

ForwardX11 yes
Tunnel yes

with no luck. Not even sure if Tunnel is relevant. Also tried ssh -Y (not -X) with setting "ForwardX11Trusted yes" is ssh_config. No luck.

Reik Red <reikred>
Mon 09 Feb 2015 10:23:00 AM UTC, comment #18: 

I could reproduce the bug with a third machine, also running
openSUSE 13.1. ssh-ing into my desktop machine and running octave gui, or ssh-ing into the server machine and running octave gui reproduced the bug. I also tried connecting from my desktop to the third machine - the same thing happened. I updated all three machines to octave 3.8.2 (from 3.8.1) and tried everything all over again, but the problem persists. The TERM variable is xterm in all three cases and I could not see any errors logged in /var/log/messages or Xorg.0.log.

Finally, I tried using octave on the server from a fourth machine, this one running openSUSE 12.3 (i586). The problem persisted.

Gabor Demeter <gdemeter>
Fri 06 Feb 2015 06:21:39 PM UTC, comment #17: 

I will mark the bug confirmed since two people can reproduce it.  It works for me (Linux<->Linux) so I can't be much help debugging it.

Rik <rik5>
Project Administrator
Fri 06 Feb 2015 06:03:28 PM UTC, comment #16: 

No luck reproducing the issue on a CentOS 5 X client.

I even brought up an Octave instance on both machines at the same time, forcing the TERM variables to be identical (xterm-256color), and looking at the environment before running octave. I doubt there is anything interesting here, but FYI, here's the dump from the Mac session:

XDG_SESSION_ID=19
COMP_WORDBREAKS=
"'><;|&(:
TERM=xterm-256color
SHELL=/bin/bash
XDG_SESSION_COOKIE=38987f7e1ebf3d2a0c1f716a5165ac9c-1423245494.805414-1292460863
SSH_CLIENT=65.36.82.183 50128 22
SSH_TTY=/dev/pts/8
USER=mcgrant
MAIL=/var/mail/mcgrant
PATH=/opt/octave/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
QT_QPA_PLATFORMTHEME=appmenu-qt5
PWD=/home/mcgrant
LANG=en_US.UTF-8
SHLVL=1
HOME=/home/mcgrant
LOGNAME=mcgrant
SSH_CONNECTION=65.36.82.183 50128 171.64.92.38 22
XDG_RUNTIME_DIR=/run/user/1006
DISPLAY=localhost:12.0
_=/usr/bin/env

Michael C. Grant <mcgrant>
Fri 06 Feb 2015 05:53:17 PM UTC, comment #15: 

I had already done a variety of TERM finagling, but the xterm idea I hadn't tried. Alas, no luck. From both an xterm (TERM=xterm) and a Mac terminal (TERM=xterm-256color), the behavior is the same; changing to TERM=aquaterm or TERM=blech does nothing different. In all cases, the TERM value is successfully delivered to the remote host.

One thing I should try is to see if can induce the behavior reliably on a Linux viewer.

Michael C. Grant <mcgrant>
Fri 06 Feb 2015 05:35:48 PM UTC, comment #14: 

For whatever its worth, I did one more test:

I tried connecting to the same server with ssh, then reconnecting to my desktop machine via ssh and running octave. So now I had my own desktop running it (version 3.8.1 this time), but tunneling the output there and back to the other machine. The bug showed up just as it had before - the command window was empty, but everything else was functional.

Gabor Demeter <gdemeter>
Fri 06 Feb 2015 05:06:52 PM UTC, comment #13: 

Michael Grant is the only one who seems to have a reliable way to reproduce this bug by connecting between a Linux server and a Mac client.  Perhaps he can test the possible problems with the TERM variable.  Maybe starting a true xterm on the Mac client and using that to ssh to the Linux machine and run Octave.  Or ssh to the Linux machine and verify that the TERM variable is not set to a Mac-specific terminal like aquaterm.

Rik <rik5>
Project Administrator
Fri 06 Feb 2015 05:02:36 PM UTC, comment #12: 

Yes, the problem persists with version 3.8.2

I tried switching fonts in Preferences, but it didn't help.
I also tried redirecting the errors by launching with the command:
octave --force-gui &>errs.txt
but the file remained empty.

I tried to build a version from the development sources, but I did not succeed. First I had various libraries missing, which I could fix easily. Then libraries for openGL and Qt were not located by the configure script (though some were installed), so I added some more I thought may help. Eventually the configure script did mark the GUI for compilation, but the process stopped with an error.
I have attached the output of the configure script and the
last few lines of the output that make produced.

The problem is, that there are a lot of Qt and openGL related packages that I can install from the opensuse repositories and I am really confused about what is necessary, what is unnecessary and perhaps what is outright detrimental. If you can give me tips on what I should install and what not, I'll give it another shot.

(file #33017, file #33018)

Gabor Demeter <gdemeter>
Thu 05 Feb 2015 09:58:30 PM UTC, comment #11: 

What rik5 comment about fonts could be relevant.  If X is having a problem finding a font in the terminal emulation code, no characters would appear.  Given your setup is a remote connect, might any possible error messages to stderr be lost in the ether?

Dan Sebald <sebald>
Thu 05 Feb 2015 05:21:38 PM UTC, comment #10: 

@Gabor: Your report is interesting because if the ssh session was between two identical Linux systems there really shouldn't be an issue.  Is there still a problem for you today with 3.8.2?  And do you have the ability to build a version from the development sources in Mercurial?

Rik <rik5>
Project Administrator
Thu 05 Feb 2015 11:50:43 AM UTC, comment #9: 

Let me add my observations to the discussion.

I have started observing the very same symptoms as described in the original submission. I have now also verified that the command window 'works' (I can create variables, run commands, save results) only I don't see anything. I didn't think to check this before. Now the curious part: I used version 3.8.1 octave and it worked well. Both machines I use (the one on my desktop and the remote one that runs octave) have openSUSE 13.1 (Bottle) (x86_64) installed, and octave installed from the opensuse repositories.
Some time last autumn I suddenly encountered this problem from one day to another, i.e. using octave gui through an ssh -X remote login worked well for months on my systems. Unfortunately I don't recall the precise circumstances, I had urgent work to finish so I reverted to using octave without the gui. I later updated to octave 3.8.2, but the problem persisted.

The bottom line is: the problem exists and in my case, it appeared after some normal functioning all of a sudden.

Gabor Demeter <gdemeter>
Tue 03 Feb 2015 07:05:02 PM UTC, comment #8: 

The GUI command window is running a terminal emulator and it needs to know what kind of terminal to strive for.  On my Linux machine, the TERM variable is set to xterm, and everything works fine.  If I set the TERM variable to aquaterm in my .tcshrc file then tcsh complains and falls back to using "dumb terminal settings".  When I run the GUI with this set-up I still get text displayed, but when I type 'ls' I get 'WARNING: terminal is not fully functional'.  

So the terminal is important, but I don't know if that is the real problem here.

Rik <rik5>
Project Administrator
Tue 03 Feb 2015 06:52:01 PM UTC, comment #7: 

I've already played with color issues (see below). I know it's not that. I've also attempted to copy and paste text from the window; there is nothing to copy.

Pardon my ignorance here, but it's not clear to me what aquaterm or xterm has to do with it; this problem only occurs with the Octave GUI. If the command window is some sort of embedded xterm though I can see your point.

I agree with your decision not to require this to be fixed by 4.0.

Michael C. Grant <mcgrant>
Tue 03 Feb 2015 06:48:18 PM UTC, comment #6: 

There is an acceptable workaround so I'm not going to require that this be fixed ahead of the 4.0 release (http://wiki.octave.org/Bug_Fix_List_-_4.0_Release).

Other things you might play with, is it just a color issue of white text on white background?  You might try changing the preferences for colors in the Terminal tab of File->Preferences.

There might also be some environment variable about the terminal that needs to get set when running cross-platform.  For instance, the TERM variable seems to be forwarded from the client to the server.  But that won't work well if your client is a Mac and has a terminal like aquaterm.  The Linux server wants something like xterm or vt100.

See http://earthwithsun.com/questions/725853/what-environment-variables-are-set-when-i-use-ssh.

Rik <rik5>
Project Administrator
Tue 03 Feb 2015 06:23:11 PM UTC, comment #5: 

OK, we're gettting somewhere. The rendering problem does not occur when I use a CentOS X11 client.

This certainly makes this problem a lower priority since most users are going to be rendering the GUI locally.

Thanks for the suggestion!

Michael C. Grant <mcgrant>
Tue 03 Feb 2015 06:16:25 PM UTC, comment #4: 

I'm afraid this one's a bit of a challenge because it's a remote machine I don't have local access to. I'll see if I can reproduce this with a Linux X11 client.

Running --no-gui-libs works fine, including the plot command, which again doesn't surprise me given that all other windows work.

Good idea about the stable version. I don't have access to 3.8.2, but I did install 3.8.1 from using apt-get. It looks like the same problem occurs there as well.

Michael C. Grant <mcgrant>
Tue 03 Feb 2015 05:53:07 PM UTC, comment #3: 

This works for me, but I am ssh'ing between two Linux machines.

Can you verify that it works Linux<->Linux by ssh'ing from the Ubuntu box into the same Ubuntu box?  I assume this will work.

Does X forwarding work for other applications to the Mac?

What happens if you run the non-gui version of Octave?

octave -f --no-gui-libs
graphics_toolkit fltk
plot (1:10)

Does the command line and plot show up?

Finally, do you have access to the stable version 3.8.2 on Ubuntu?  If so, what happens when you run

octave-3.8.2 -f --force-gui

Rik <rik5>
Project Administrator
Tue 03 Feb 2015 04:53:02 PM UTC, comment #2: 

I'm afraid not. More details:

- the cursor appears in the top left corner of the window. (as shown in the screenshot). I changed the cursor type and color, and it was updated properly.
- I also tried keeping the window docked but separated from the editor & documentation.
- Changing the colors doesn't seem to matter.

Indeed, given that the cursor remains in the proper place, it seems like the failure is not in rendering, but in the delivery of the text to the window.

Michael C. Grant <mcgrant>
Tue 03 Feb 2015 04:46:30 PM UTC, comment #1: 

Does changing fonts have any effect?

Foreground or background colors for the terminal?

To change these, use the File -> Preferences menu then select Terminal tab from the dialog.

John W. Eaton <jwe>
Project Administrator
Tue 03 Feb 2015 04:16:41 PM UTC, original submission:  

I checked out the Mercurial repo, bootstrapped, and built on 64-bit Linux (Ubuntu 14.04.1 LTS). Compilation proceeded without incident.

To test, I executed ./run-octave over an SSH connection with X forwarded to my local machine (Mac OSX 10.10.2, Xquartz 2.7.7). The command window is blank, no matter whether it is docked or undocked. It still accepts input, however. All other windows seem to render properly.

Attached is a screenshot. I typed blind, and ran some code that generated a couple of plots, so you can see that the directory, history, workspace, and plot windows all render properly. If you'll take my word for it, the editor and documentation windows work fine too.

Michael C. Grant <mcgrant>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #33017:  configure.txt added by gdemeter (71KiB - text/plain)
file #33018:  compile_end.txt added by gdemeter (3KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by wdeninger (Posted a comment)
  • -email is unavailable- added by reikred (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by gdemeter (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mcgrant (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-09 rik5 Carbon-CopyRemoved 72865 => -
    2015-02-06 rik5 StatusWorks For Me => Confirmed
    2015-02-06 gdemeter Attached File- => Added configure.txt, #33017
        Attached File- => Added compile_end.txt, #33018
    2015-02-03 rik5 StatusNone => Works For Me
    2015-02-03 mcgrant Attached File- => Added Screen Shot 2015-02-03 at 9.59.32 AM.png, #32986

    Back to the top


    Powered by Savane 3.5