bugGNU Octave - Bugs: bug #44840, Plotting with Qt or FLTK from...

 
 

bug #44840: Plotting with Qt or FLTK from remote system fails

Submitter:  Michael Godfrey <godfrey>
Submitted:  Wed 15 Apr 2015 04:11:09 AM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Confirmed Assigned to:  None
Originator Name:  Godfrey Open/Closed:  * Closed
Release:  * 4.0.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 23 Jul 2016 09:49:19 PM UTC, comment #22: 

Finally, recent updates to X11 and likely other
components is Fedora 24 have fixed ALL the problems
reported here, including print (both locally and remote)
with "visible" "on".

Michael Godfrey <godfrey>
Group Member
Mon 09 May 2016 10:17:43 PM UTC, comment #21: 

I tried another test:
ssh <from Mac Power Book Pro running
El Capitain 10.11.4  to a Linux fedora 23 system.

The result is:

octave --no-gui

>> plot(1:20)

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

>> grid on
>> print zzz.pdf
>> quit


The plot appears correctly and the generated PDF is
correct.

No need to manipulate visibility!

This was not what I expected.

So, in the Mac -- Fedora environment with Octave only
on the Fedora machines the only failure
is Fedora to Fedora!

Michael Godfrey <godfrey>
Group Member
Sun 08 May 2016 05:04:54 PM UTC, comment #20: 

I just reviewed the history of this report. The entry that
I made below is quite different from the previous problems.

So, I would recommend working on the current problem as described
in comment #19, and ignore the previous issues.

Michael

Michael Godfrey <godfrey>
Group Member
Sun 08 May 2016 04:54:38 PM UTC, comment #19: 

Mike said:
You actually reported this last year, and bug #44840 is still open, nothing
has changed, closing as a duplicate.

Right, a year is a pretty long time and I forgot and this
is now version 4.1.0+. So, that could be updated.

But, I also attached a dump trace to where it hangs and
additional information. The information is:
The following:
ssh "remote linux system" (in my case remotethe system is
the same
Fedora 23 as the local host)
++verbatim
cd to octave build directory
./run-octave --no-gui --debug --echo
plot(1:100)
--verbatim--
Result:
The frame for Figure 1 appears, but then system
hangs before plotting any data.
Output up to the hang is attached.
If you run just
./run-octave
on the remote system, the GUI appears and works until
a plot command is used. Then it hangs as before.
This also fails on release 4.0.1, but I am
pretty sure that this worked at some point in the
past.
As the Summary says, using toolkit gnuplot works.

A trace of the code to the hang is attached.

Most of the history in this report is now pretty irrelevant,
but Mike preferred to continue this report.


(file #37103)

Michael Godfrey <godfrey>
Group Member
Tue 02 Jun 2015 04:47:16 PM UTC, comment #18: 

Retagging release from 4.0.0-rc3 to 4.0.0.

John W. Eaton <jwe>
Group administrator
Wed 22 Apr 2015 04:27:52 PM UTC, comment #17: 

This appears to affect quite a few systems. Should
it be considered a blocker? jwe seemed to suggest that
he knew something about how to fix it...

Michael Godfrey <godfrey>
Group Member
Sun 19 Apr 2015 12:55:32 PM UTC, comment #16: 

Correct typo:
Useful tool if you are wotking on a system with X11 but

should read:
Useful tool if you are working on a system without X11 but

Michael Godfrey <godfrey>
Group Member
Sun 19 Apr 2015 02:19:00 AM UTC, comment #15: 

Using xvfb-run make all
stopped at

  MAKEINFO octave.info
./plot-surfaceproperties.texi:200: @xref reference to nonexistent node `XREFlinelinewidth'
./plot-surfaceproperties.texi:212: @xref reference to nonexistent node `XREFlinemarkeredgecolor'
./plot-surfaceproperties.texi:218: @xref reference to nonexistent node `XREFlinemarkerfacecolor'
./plot-surfaceproperties.texi:224: @xref reference to nonexistent node `XREFlinemarkersize'
Makefile:2116: recipe for target 'octave.info' failed
make[3]: * [octave.info] Error 1
make[3]: Leaving directory '/home/godfrey/d/src/octave/hg/octave/doc/interpreter'
Makefile:1903: recipe for target 'all-recursive' failed
make[2]: * [all-recursive] Error 1
make[2]: Leaving directory '/home/godfrey/d/src/octave/hg/octave/doc'
Makefile:2121: recipe for target 'all-recursive' failed
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory '/home/godfrey/d/src/octave/hg/octave'
Makefile:1984: recipe for target 'all' failed
make: * [all] Error 2
================================
But:

xvfb-run make -i all
xvfb-run make -i check

Does better:

Summary:

  PASS     12892
  FAIL         1
  XFAIL       14
  SKIPPED     84
===========================
But, of course, no doc was generated and the octave that
was produced is just like the previous.

Useful tool if you are wotking on a system with X11 but
plan to use the executable on one that has working
graphics.



Michael Godfrey <godfrey>
Group Member
Sun 19 Apr 2015 01:51:54 AM UTC, comment #14: 

Does building with xvfb-run work for you? On autobuilders with no X display, we build with:


$ xvfb-run make all
$ xvfb-run make check


Mike Miller <mtmiller>
Group Member
Sun 19 Apr 2015 12:45:20 AM UTC, comment #13: 

Addition to comment bellow: A FULL build including
the doc fails when the doc processing tries to use
plotting calls. However, at that point Octave has
been built, so it can be installed. The install also tries
to build the doc, but fails.

So, a way to force software rendering at both build and
execution time does seems a good idea.

Michael Godfrey <godfrey>
Group Member
Fri 17 Apr 2015 04:12:27 AM UTC, comment #12: 

Added data for Intel HD 6000 systems: A build
on the system goes through fine, but
make check
hangs at the graphics.cc test
2 cntrl-C's are required to force exit.

This is not a surprise since plots fail using
a system that was compiled on another system
which hd Intel HD 5000 graphics hardware.

Michael Godfrey <godfrey>
Group Member
Wed 15 Apr 2015 11:53:14 PM UTC, comment #11: 

John: Is there a way of unconditionally forcing software
rendering as a test?

This might even make the HD 6000 systems work!

Michael Godfrey <godfrey>
Group Member
Wed 15 Apr 2015 11:44:47 PM UTC, comment #10: 

So I guess the question is how do we detect this situation and switch to software rendering?

John W. Eaton <jwe>
Group administrator
Wed 15 Apr 2015 09:50:37 PM UTC, comment #9: 

Mike: Here is output when Matlab starts up:

[godfrey@isl ~]$ matlab -nodesktop
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965
MATLAB is selecting SOFTWARE OPENGL rendering.

>>     x = -pi:pi/10:pi;
>>        y = tan(sin(x)) - sin(tan(x));
>>        plot(x,y,'--rs','LineWidth',2,...

                       'MarkerEdgeColor','k',...
                       'MarkerFaceColor','g',...
                       'MarkerSize',10)
Warning: MATLAB has disabled some advanced graphics rendering features by switching to software
OpenGL. For more information, click <a href="matlab:opengl('problems')">here</a>.

>> 

======================the plot appears OK.

Michael Godfrey <godfrey>
Group Member
Wed 15 Apr 2015 09:41:20 PM UTC, comment #8: 

John,
I just realized an important fact: the remote system
on which I ran glxgears in my previous comments is one with
Intel HD Graphics 6000 which apparently is not supported
correctly in any Fedora release.

Sorry!

Michael Godfrey <godfrey>
Group Member
Wed 15 Apr 2015 09:32:09 PM UTC, comment #7: 

John,

Sure:

[godfrey@pbdsl5 ~]$ glxgears -info

^C
[godfrey@pbdsl5 ~]$
i.e. nothing.

I also tried under gdb:
Starting program: /usr/bin/glxgears
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
^C
Program received signal SIGINT, Interrupt.
0x00007ffff722dc70 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81
81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Missing separate debuginfos, use: debuginfo-install expat-2.1.0-10.fc21.x86_64 libXau-1.0.8-4.fc21.x86_64 libXdamage-1.1.4-6.fc21.x86_64 libXext-1.3.3-2.fc21.x86_64 libXfixes-5.0.1-4.fc21.x86_64 libXxf86vm-1.1.3-4.fc21.x86_64 libdrm-2.4.60-1.fc21.x86_64 libselinux-2.3-5.fc21.x86_64 libxcb-1.11-3.fc21.x86_64 libxshmfence-1.2-1.fc21.x86_64 pcre-8.35-8.fc21.x86_64 xz-libs-5.1.2-14alpha.fc21.x86_64
(gdb) bt
#0  0x00007ffff722dc70 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff4e3c182 in _xcb_conn_wait () from /lib64/libxcb.so.1
#2  0x00007ffff4e3da8f in wait_for_reply () from /lib64/libxcb.so.1
#3  0x00007ffff4e3dba1 in xcb_wait_for_reply () from /lib64/libxcb.so.1
#4  0x00007ffff7b8fa39 in dri3_open (provider=0, root=172, dpy=<optimized out>) at dri3_glx.c:1658
#5  dri3_create_screen (screen=0, priv=<optimized out>) at dri3_glx.c:1897
#6  0x00007ffff7b60aa1 in AllocAndFetchScreenConfigs (priv=0x612220, dpy=0x606030) at glxext.c:788
#7  __glXInitialize (dpy=dpy@entry=0x606030) at glxext.c:902
#8  0x00007ffff7b5d1ab in GetGLXPrivScreenConfig (dpy=dpy@entry=0x606030, scrn=scrn@entry=0,
    ppriv=ppriv@entry=0x7fffffffdc60, ppsc=ppsc@entry=0x7fffffffdc68) at glxcmds.c:172
#9  0x00007ffff7b5da23 in GetGLXPrivScreenConfig (ppsc=0x7fffffffdc68, ppriv=0x7fffffffdc60,
    scrn=0, dpy=0x606030) at glxcmds.c:168
#10

Michael Godfrey <godfrey>
Group Member
Wed 15 Apr 2015 09:24:39 PM UTC, comment #6: 

Could you also try


glxgears -info


and paste the output here?

John W. Eaton <jwe>
Group administrator
Wed 15 Apr 2015 08:08:42 PM UTC, comment #5: 

John,

Trying glxgears provided some information:
In my case Fedora 21 to fedora 21 glxgears fails
with no messages.
But between fedora 20 and fedora 21 it runs fine
with messages:
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965
11 frames in 5.2 seconds =  2.101 FPS
13 frames in 5.3 seconds =  2.433 FPS
10 frames in 6.0 seconds =  1.660 FPS
============================
but, Octave still fails as before: window with
title Figure 1 appears, but no data or axes.


Michael Godfrey <godfrey>
Group Member
Wed 15 Apr 2015 06:29:11 PM UTC, comment #4: 

A simpler test is whether glxgears works across the ssh connection.  If that doesn't work, then I don't see how Octave can use OpenGL across the ssh connection.  But if it does work, then maybe we can look at glxgears to determine what needs to be done to also make Octave work.

John W. Eaton <jwe>
Group administrator
Wed 15 Apr 2015 04:21:33 PM UTC, comment #3: 

Is there a way to tell if Matlab is actually using OpenGL when you are testing a particular plot remotely like this? Or plot something that would require OpenGL, a 3D surface maybe, and see if it works in a remoted Matlab using these same machines? It is true that Matlab only uses OpenGL for certain plots, not for simple line plots, while of course Octave uses OpenGL for everything?

Mike Miller <mtmiller>
Group Member
Wed 15 Apr 2015 03:46:14 PM UTC, comment #2: 

I am not surprised that it works for some combinations of
systems. I tried it between Fedoras (20 and 21) which usually
work. Also, the test I ran using Matlab was between the systems
that failed for Octave.

And, I know all too well about the complexities of X11, differing
systems, etc.

Still it would be very useful to make this better. I will try
to do more diagnosis, but this cannot happen for a few weeks.

Michael Godfrey <godfrey>
Group Member
Wed 15 Apr 2015 01:25:55 PM UTC, comment #1: 

Thanks for reporting this Michael. This has come up before, but I don't know if a bug was ever reported.

I honestly think that this depends on many, many variables, including the versions of Mesa on both the remote and local machines, the capabilities of the X server running on the local machine, and the video driver loaded by the local X server and how it is configured.

I have definitely seen this error before on certain combinations of machines. But right now I am able to plot perfectly between my client and a server that has Octave 3.8.2 remoting FLTK plots back to my client.

I think I have also seen this error when trying to plot to a VNC X display or to a nested X display (Xnest or Xephyr), but again I think I have also seen it work in some of those scenarios, depending on versions, etc.

Marking as confirmed even though I can't reproduce it right now.

Mike Miller <mtmiller>
Group Member
Wed 15 Apr 2015 04:11:09 AM UTC, original submission:  

It appears that this has not worked since FLTK was first
introduced. I tried 3.8.2 and the current 4.0.0-rc3.

If you ssh to another machine (with X11Forwarding ON) and
type plot(1:200) the outtine Figure appears but no data are
plotted and the command hangs. Neither fltk nor Qt work.
Of course, gnuplot still "works." Over the same connection
the standard X11 programs (like xclock) work correctly, so the
problem is in Octave. And, Matlab, running on the same systems,
works, so this is also a Matlab incompatibility.

To reproduce this:

ssh -X remote-machine (X only needed if X11Forwarding is not on)
octave
plot(1:200)
======================
at this point an incomplete plot appears and Octave hangs.

I am surprised that this has not been rported already, but
I found no relevant bug report.

Michael Godfrey <godfrey>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #37103:  octave_remote_hang_May_7_2016_bug47873 added by godfrey (11KiB - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by godfrey (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-24 jwe Open/ClosedOpen Closed
    2016-05-08 godfrey Attached File- Added octave_remote_hang_May_7_2016_bug47873, #37103
    2016-05-08 mtmiller Dependencies- bugs #47873 is dependent
    2015-06-02 jwe Release4.0.0-rc3 4.0.0
    2015-04-15 mtmiller StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code