@Pantxo,

Sorry for the delayed reply. I'm able to build. How may I verify gnuplot wasn't used to build the images?

I pushed the patch from comment #38 on stable, for Mac only, and then on default for all platforms:

http://hg.savannah.gnu.org/hgweb/octave/rev/e6bc258df691
http://hg.savannah.gnu.org/hgweb/octave/rev/7206b8c222eb

Marking this bug ready for test.

@Rik,

The seg-fault occurs with and without the patch. Closing the figure does not help.

One of the changesets since 5e247fb245f2 has introduced a new problem. I now see seg-fault when creating the text-files.

@Pantxo,

With your patch, and two other patches, I can eventually  build the docs on macOS (occasional crashes).

However, if I run manually and plot, octave reliably crashes on exit (both qt and fltk)

>> graphics_toolkit
ans = qt
>> peaks ()
>> quit
fatal: caught signal Segmentation fault: 11 -- stopping myself...
Segmentation fault: 11

In case anyone is interested in the crash logs, I've attached them.


(file #46111, file #46112)

@Pantxo: I think it is okay to push to stable.  The idea right now is to find errors in the build system with RC1 and fix them which this certainly does.

Does this have any negative consequences for non-Mac users?  It appears that this change is made for all operating systems.  One possibility if we are concerned about limiting any potential side effects would be to use an #ifdef/#end around the code which is Mac specific.  I compiled on a Linux system and 'make check' passes so I suppose that is a small level of testing.  I don't know about Windows.

This is just a small observation, but it is often easier to understand the code if it can be read directly from top to bottom.  If there branches in control flow then it is best practice to put the branch which is taken most often first so that reading continues easily.  In the current code, the rare case ("visible" == "off") is listed first and when following normal execution one has to search for the else clause.  Also, the local variables "pos" and "dpr" are only necessary in one of the branches of code.  Instead of declaring them above the if statement, I would move them in to the block that is Mac-specific since that is the smallest enclosing scope.

fixed the patch after jwe's changeset 98afb8bbd1f6



(file #46092)

@Ben: Well, I'd not call this an improvement :-). It is very strange since this message should only appear if "__have_feature__ ("QT_OFFSCREEN") == 0", i.e. if the test for usability of QOffscreenSurface has failed at configure time. This feature used to be present in your previous builds (or print wouldn't have gone that far). Did you reconfigure before building?

• If so can you look at the config.log and see what went wrong? My patch should not affect the configure test.
• If not, are you using the fltk toolkit? This would explain that.

With file #46075 the situation has improved

>> figure ("visible", "off");
>> plot (1:10)
>> print toto.eps
error: print: figure must be visible or qt toolkit must be used with __gl_window__ property 'on' or QT_OFFSCREEN feature available
error: called from
    __opengl_print__ at line 195 column 7
    print at line 710 column 16

Is Dimitri's suggestion related? If so where do I set that flag?

Sorry, wrong version of the patch. The correct one is attached.

(file #46077)

@Rik

toto_visible.eps looks ok, but toto.eps is empty (see attached)

When gl2ps was added, I recall that it was necessary to render the figure on screen to work. Is that no longer the case for Linux?

AFAIK, rendering on screen is still needed for macOS.

(file #46074, file #46075)

Ugh.  So maybe on Macs we can't get a valid OpenGL context without having shown a visible figure first?

@Ben: What happens if you change the order of execution?

figure ();
plot (1:10)
print toto_visible.eps
set (gcf, "visible", "off")
clf;
plot (10:-1:1);
print toto.eps

@Ben: Ok. So this is definitely due to printing with gl2ps. If you start an Octave session and no previous figure have been open, does the following work?

figure ("visible", "off");
plot (1:10)
print toto.eps
set (gcf, "visible", "on")
print toto_visible.eps

Those should make use of two different opengl contexts, first an offscreen one, second a "standard" one.

@Ben: The image in comment #17 calls for a few comments ... I would not say that the "plot is created correctly" :-): only do text objects appear to be printed. In fact those objects are not dependent on opengl working since we generate the ps code ourselves.
So my conclusion would be more like "plotting doesn't work for eps and derived".
Do png files, which don't use the same code path by default (no gl2ps), look better or worse?
Do you observe the same warnings and crappy printouts when printing visible figures? Does the simple script below generate correct figures?

figure ("visible", "on");
plot (1:10)
print toto.png
print toto.eps

The plot extended.eps is created using the "pdflatexstandalone" which is quite unusual.  That could be one source of the problem.  The other thing is that plotimages.m calls system ("pdflatex").  Does the system() call which involves a fork and creation of a new process work on a Mac?  I recall that there are strange problems with multi-threading.

attached

(file #46021)

I'm seeing a seg-fault when Octave exits (unrelated). The plot is created correctly.

/bin/sh run-octave --norc --silent --no-history --path /Users/bpabbott/Development/mercurial/default/sources/doc/interpreter/ --eval "graphics_toolkit qt ; plotimages ('doc/interpreter/', 'extended', 'eps');"
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred in init_gl_context
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 710 column 16
    plotimages at line 111 column 7
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred drawing 'text' object
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 710 column 16
    plotimages at line 111 column 7
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred drawing 'text' object
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 710 column 16
    plotimages at line 111 column 7
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred drawing 'text' object
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 710 column 16
    plotimages at line 111 column 7
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred drawing 'line' object
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 710 column 16
    plotimages at line 111 column 7
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred drawing 'line' object
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 710 column 16
    plotimages at line 111 column 7
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred drawing 'text' object
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 710 column 16
    plotimages at line 111 column 7
fatal: caught signal Segmentation fault: 11 -- stopping myself...
Segmentation fault: 11

I alsoI tried the patch posted by Pantxo in bug #48519. Like Carlo, it does not solve this problem for me.

Indeed the issue in bug #48519 looks similar to this one.
I am bug #48519 setting as a dependency.

@Ben, @Carlo: How would you like to proceed on this bug report?  mkfifo is now working again so gnuplot is an option.

Also, there is an extreme memory leak in the graphics subsystem that needs to be fixed before the 5.0 release.  It might be worth waiting until after that bug has been resolved because it may have knock-on effects which improve other parts of the graphics operation.

@Carlo,

I've seen occasional problems building the docs for years. But when random (about 20% of the time) it is very difficult to debug. Recently, it was not random for me and failed 100% of the time. Unfortunately, I didn't / don't have the time necessary for debugging this problem..

Except that it looks like gnuplot also isn't working on macOS: bug #55273.

@Ben I have always experienced the randomness of the failure, with or without the workaround.

Indeed if relaunching make over and over after each failure it
is possible to complete the docs, eventually.

Actually this is some times needed even with the "pause" workaround applied, it simply reduces the probability of encountering the  failure and thus the number of attempts needed to complete the build.

Actually, I never expected the "pause" to be a real solution,
but it makes a bit less tedious to get a finalized build with which to run meaningful tests.

With old revisions of the 5.* series the probability of failure was very high
and the number of restarts really large, I am not sure whether or not this ha improved recently.

@Carlo,

Now that dev is version 6.0.0, building the docs without your work around makes a lot of progress before failure. Can you confirm?

/bin/sh run-octave --norc --silent --no-history --path /Users/bpabbott/Development/mercurial/default/sources/doc/interpreter/ --eval "plotimages ('doc/interpreter/', 'extended', 'eps');"
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred in init_gl_context
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 709 column 16
    plotimages at line 111 column 7
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred drawing 'text' object
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 709 column 16
    plotimages at line 111 column 7
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred drawing 'text' object
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 709 column 16
    plotimages at line 111 column 7
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred drawing 'text' object
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 709 column 16
    plotimages at line 111 column 7
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred drawing 'line' object
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 709 column 16
    plotimages at line 111 column 7
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred drawing 'line' object
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 709 column 16
    plotimages at line 111 column 7
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred drawing 'text' object
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 709 column 16
    plotimages at line 111 column 7

/bin/sh run-octave --norc --silent --no-history --path /Users/bpabbott/Development/mercurial/default/sources/doc/interpreter/ --eval "sparseimages ('doc/interpreter/', 'gplot', 'eps');"
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred in init_gl_context
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 709 column 16
    sparseimages at line 46 column 5
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred drawing 'line' object
warning: called from
    __opengl_print__ at line 193 column 7
    print at line 709 column 16
    sparseimages at line 46 column 5
fatal: caught signal Segmentation fault: 11 -- stopping myself...
make[2]: *** [doc/interpreter/gplot.eps] Segmentation fault: 11
make[2]: *** Deleting file `doc/interpreter/gplot.eps'
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2