Documentation failing to build because of geometryimages in FLTK (was Re: the nvidia/osmesa dilema)

[Daniel J Sebald]

On 05/04/2016 04:15 PM, Daniel J Sebald wrote:
> On 05/04/2016 11:58 AM, John W. Eaton wrote:
> > On 05/04/2016 12:47 PM, John W. Eaton wrote:
> > > On 05/04/2016 06:36 AM, Juan Pablo Carbajal wrote:
> > > > hi all,
> > > >
> > > > We still have this issue with building the documentation and running
> > > > tests (https://savannah.gnu.org/bugs/?44478) that casues segfaults
> > > > when the user is running with nvidia drivers.
> > >
> > > I keep forgetting that the system I have with an nvidia graphics card is
> > > using the nouveau driver, not the proprietary nvidia driver.  So I'll
> > > try installing the nvidia driver and see if I can reproduce the crash.
> >
> > OK, with the nvidia driver installed, I get a crash for the following:
> >
> >    figure visible off
> >    sombrero
> >    print invisible.pdf
> >
> > I'll try to do some debugging soon.
>
> Both
>
>    nvidia-340 (recommended)
>    Version 340.96-0ubuntu0.14.04.1
>    NVIDIA binary driver - version 340.96
>
> and
>
>    xserver-xorg-video-nouveau (open-source)
>    Version 1:1.0.10-1ubuntu2
>    X.Org X server - Nouveau display driver
>
> work with the above set of commands when launching the GUI, and the
> former works for
>
>    run-octave --no-gui
>    run-octave --no-window-system
>
> But the documentation still fails with an "octave exited with signal 11"
> error message.  There could be multi issues here.  I'll try isolating
> the documentation build issue.

OK, for the documentation, it is this geometry images routine that is 
failing:

./run-octave --path /home/sebald/octave/octave/octave/doc/interpreter/
> > geometryimages ('doc/interpreter/', 'griddata', 'eps');

The routine runs for a while and then crashes the GUI and all.

The above command works fine with gnuplot.  But it appears as though 
something isn't programmed correctly in the FLTK driver and or 
geometryimages() program.

I tried breaking this down to the bear minimum commands, and I'll 
explain what I'm seeing, and I'll post this to a bug report to build on, 
either existing or new.  If it sounds like a familiar bug report, please 
point me to it.

Inside of file geometryimages.m of the build directory I've put a number 
of text strings to verify it is this command:

    print (outfile, d_typ);

that is last run before the crash, but I think it is the FLTK code 
leading up to it and then tries printing nonsensical results that is 
causing the crash.  Try commenting out this line:

diff --git a/doc/interpreter/geometryimages.m 
b/doc/interpreter/geometryimages.m
--- a/doc/interpreter/geometryimages.m
+++ b/doc/interpreter/geometryimages.m
@@ -19,7 +19,7 @@
 function geometryimages (d, nm, typ)
   set_graphics_toolkit ();
   set_print_size ();
-  hide_output ();
+%  hide_output ();
   outfile = fullfile (d, [nm "." typ]);
   if (strcmp (typ, "png"))
     set (0, "defaulttextfontname", "*");

Now run

./run-octave --no-gui --path 
/home/sebald/octave/octave/octave/doc/interpreter/
> > geometryimages ('doc/interpreter/', 'griddata', 'eps');

What I'm seeing happen over about three or four seconds is first there 
is a window appearing that looks like the proper plot (i.e., similar to 
what I've seen in gnuplot).  Then immediately it is erased and the same 
image redrawn in a 0.5 magnification on the left side of the same 
window.  Again, this is immediately erased and then an image about 0.25 
magnification is redrawn on the left side of the same window.  After 
that seems to be a bit of few odd lines drawn at random places and the 
window disappears.

HOWEVER, Octave hasn't crashed.  So I hit up-arrow to rerun the command.

> > geometryimages ('doc/interpreter/', 'griddata', 'eps');
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Segmentation fault

Actually, I repeat this experiment and the drawing pattern is not quite 
the same as the first time I saw it.  This time I see the same, proper 
image redrawn be this type in a 2.0 or 3.0 magnification scale so that 
it isn't completely visible within the window.

Can someone repeat this?  This seems like a graphics toolkit code type 
of bug.  What bug report, new or existing, should I start from?

Dan