bugGNU Octave - Bugs: bug #47849, Documentation failing to build...

 
 

bug #47849: Documentation failing to build because of geometryimages.m

Submitted by:  Dan Sebald <sebald>
Submitted on:  Wed 04 May 2016 11:49:10 PM UTC  
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Duplicate Assigned to:  None
Originator Name:  Open/Closed:  Closed
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 06 May 2016 05:49:18 PM UTC, comment #13: 

This thread has had some noise, partly contributed
by me. I just build a system from an entirely clean
start and it builds just fine. The hang that I experienced
must have been due to some leftover stuff in the octave
directory that I used.

The thing to learn from this is that the current build
and install systems are not as robust as would be ideal.
Stuff gets "leftover" which leads to problems.
Some housecleaning would be useful.
Possibly a make clean which really cleans out everything
would help. Even, a make clean_install which removes
ALL or some installed systems?

In any case, closing this thread seems a very good idea.

Michael Godfrey <godfrey>
Project Member
Fri 06 May 2016 08:54:20 AM UTC, comment #12: 

Mike: Your advice to use --without-OSMesa should work
but it is also true that for current Fedora systems
this is a new problem.

It may be best to leave this report closed and open a new
report with respect to Fedora systems. And, of course, it
may only affect Fedora systems with specific hardware, etc.

Also, not all of the Manual plots generate correctly when
using gnuplot.

Michael Godfrey <godfrey>
Project Member
Fri 06 May 2016 04:13:43 AM UTC, comment #11: 

Oh, I didn't know that.  Thanks Mike.

Dan Sebald <sebald>
Fri 06 May 2016 12:26:46 AM UTC, comment #10: 

Dan, all you should need to do is build with --without-OSMesa (capitalization is important). Octave will not link in the OSMesa libraries, and building the documentation will fall back to using gnuplot, problem solved.

Then if you are having problems building the documentation with gnuplot, that is definitely a separate bug and should be reported.

Mike Miller <mtmiller>
Project Administrator
Thu 05 May 2016 11:04:16 PM UTC, comment #9: 

The current dev system is, on Fedora, a regression.
Documentation previously built OK. Now the build hangs
at:
  GEN      doc/interpreter/voronoi.txt

Michael Godfrey <godfrey>
Project Member
Thu 05 May 2016 09:14:59 PM UTC, comment #8: 

Feel free to close.  I'm not sure there is a solution for the nVidia behavior and OSMesa simultaneously.  I'm disable documentation building again.

Here are a couple more links to something that may be an alternative to OSMesa:

https://www.opengl.org/discussion_boards/showthread.php/125898-Off-screen-rendering-in-Qt-OpenGL

http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.txt

Someone from NVIDIA was involved in this extension.  Too much to read at one sitting, so whether this extension was intended as a general solution to all openGL frameworks, or just NVIDIA's setup, I'm not sure.

Dan Sebald <sebald>
Thu 05 May 2016 07:54:58 PM UTC, comment #7: 

So to sum up, we already know off-screen printing with OSMesa fails when you are using nvidia's proprietary libGL library, this is bug #44478.

Is there anything different about this bug that warrants leaving it open?

Mike Miller <mtmiller>
Project Administrator
Thu 05 May 2016 08:45:18 AM UTC, comment #6: 

I'm just writing some notes here so that I can come back to some lines of thought...

It boils down to that osmesa context.

I see that other projects have had problems with Qt and OSMesa simultaneously:

  https://cmake.org/Wiki/ParaView/ParaView_And_Mesa_3D_tmp

  https://cmake.org/Wiki/ParaView/ParaView_And_Mesa_3D_tmp#ParaView_with_Offscreen_Mesa

The

  OSMesaContext ctx = OSMesaCreateContextExt (OSMESA_RGBA, 16, 0, 0, NULL);

and

  if (! OSMesaMakeCurrent (ctx, buffer, GL_UNSIGNED_BYTE, Width, Height))

routines do not fail.  But OSMesa is sort of it's own openGL interface and not tied into the native graphics screen-rendering openGL...although the two eventually do interconnect when OSMesa has to do its rendering.

This routine fails:

  glGetIntegerv (GL_DEPTH_BITS, &z);

but I can put openGL command before it, such as:

  glEnable (GL_DEPTH_TEST);
  glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

I can comment out the glGetIntegerv() calls and _osmesa_print_() will continue onto rendering as though everything is fine, open the EPS file then crash leaving the EPS file behind with 0 bytes.  So, it isn't anything to do with calling a particular openGL function.

Instead, I'm wondering if nVidia driver is adhering to a strict definition of X11, and that is where the conflict lies.  Remember, Qt ultimately is using X11 under the hood.  I thought that maybe I could make the current X11 context non-current by calling this routine

https://www.opengl.org/sdk/docs/man2/xhtml/glXMakeContextCurrent.xml

with None, None and NULL, just as a means to test.  However, I don't know what the Display * is.  Qt probably has that information, but there's no way for us to get at it.  Plus, it probably isn't good to remove an existing X11 context.  The whole screen might freeze.

Anyway, so continuing with train of thought.  Here might be an important clue as to why the nVidia driver (or more accurately an X11 compliant driver) doesn't like openGL/OSMesa commands without proper care:

https://www.opengl.org/documentation/specs/glx/glx1.4.pdf

In particular, on pages 7 and 8:

"
X has atomicity (between clients) and sequentiality (within a single client) requirements that limit the amount of parallelism achievable when interpreting the command streams. GLX relaxes these requirements. Sequentiality is still guaranteed within a command stream, but not between the X and the OpenGL command streams. It is possible, for example, that an X command issued by a single threaded client after an OpenGL command might be executed before that OpenGL command.
"

and further

"
Synchronization is in the hands of the client. It can be maintained with moderate cost with the judicious use of the
glFinish, glXWaitGL, glXWaitX, and XSync commands. OpenGL and X rendering can be done in parallel as long as the client does not preclude it with explicit synchronization calls. This is true even when the rendering is being done by the X server. Thus, a multi-threaded X server implementation may execute OpenGL rendering commands in parallel with other X requests.
"

I'll investigate this a bit further.  The problem, of course, is that even if one does find a fix with an X11 synchronization function call, that isn't portable from the Qt perspective.

Another line to investigate is to see if it is possible to use the FLTK and QT rendering that works in visible mode and not have the graphics mapped into screen memory.  Probably not, but if that were possible, then _osmesa_print_ could be restricted to the case when there is no Qt or FLTK running.  If Qt is not running, then the X11/openGL threading conflict doesn't arise..  The least that could be done is to not use Qt for generating documentation, use FLTK.

Dan Sebald <sebald>
Thu 05 May 2016 03:37:44 AM UTC, comment #5: 

Ok, back from break.  Here's a quick summary of results that show printing works for visible plots, but not non-visible plots:

FLTK

sebald@ ~/octave/octave/octave $ rm invisible.pdf
sebald@ ~/octave/octave/octave $ /usr/local/src/octave/octave/build1/run-octave -cli --silent
octave:1> graphics_toolkit ('fltk')
octave:2> sombrero
octave:3> print invisible.pdf
octave:4> print invisible.pdf
octave:5> figure visible off
octave:6> sombrero
octave:7> print invisible.pdf
error: __osmesa_print__: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?
error: called from
    __opengl_print__ at line 172 column 7
    print at line 498 column 14
octave:7> print invisible.pdf
error: __osmesa_print__: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?
error: called from
    __opengl_print__ at line 172 column 7
    print at line 498 column 14
octave:7>
octave:7>

Doesn't crash but has a stencil mismatch, so the instruction number doesn't advance on of course no new invisible.pdf is created.  But invisible.pdf is created on the visible invocation.

QT

>> graphics_toolkit ('qt')
>> sombrero
>> print invisible.pdf
>> print invisible.pdf
>> figure visible off
>> sombrero
>> print invisible.pdf

and at that point I hit return and the GUI disappears with the command line result being "octave exited with signal 11".  As noted, Qt plots can freeze the command line with "sombrero" or, I think, "print".  About 60% of the time there seems to be a freeze somewhere in the above commands.

The freeze for Qt is probably a different issue.  Just interested in the crash here.  I think this is at least an starting point for investigation, so I'll take a look at this visibility and see if there is an intialization/configuration bug.

Dan Sebald <sebald>
Thu 05 May 2016 01:38:03 AM UTC, comment #4: 

Oy, must have misspelled "verbatim" and lost a detailed post again.  I'll rewrite later, but the short of it is that yes, I can print with both FLTK and Qt when in visible mode, but not when in non-visible mode.  When in non-visible mode, FLTK doesn't crash but gives warning about stencil mismatch.  Qt toolkit segfaults...with the added detail that it sometimes freezes even at the point of drawing the sombrero.

Dan Sebald <sebald>
Thu 05 May 2016 01:32:09 AM UTC, comment #3: 

I wrote a long post here describing my observations for 'qt' sometimes working and sometimes not.  It just seemed too flaky--sometimes creating a PDF file, often hanging and not always in the same location.

Anyway, just to address your question.  Yes, I was getting valid EPS files in all cases for the original post.  Let's replicate such a thing if possible with -cli option.

Dan Sebald <sebald>
Thu 05 May 2016 12:16:06 AM UTC, comment #2: 

So you're seeing the same exact segmentation fault as bug #44478. Only you're seeing it for only one image? Can you try other plots in the doc/interpreter image m-file scripts?

If they all crash the same way, then yes this is essentially bug #44478, we don't know how to make OSMesa work with the proprietary nvidia libGL implementation. If you can get any printing to a file to work with osmesa and nvidia, that's more than anyone else has been able to do.

I don't know what you're saying about gnuplot here, looks unrelated, but the segmentation fault is clearly the same as bug #44478.

Mike Miller <mtmiller>
Project Administrator
Thu 05 May 2016 12:08:44 AM UTC, comment #1: 

I've tried the following:

./run-octave -cli -g --path /home/sebald/octave/octave/octave/doc/interpreter/

and FLTK becomes the default.  It behaves similar to what I described in the previous post.  I'll instead do

./run-octave -g --no-gui --path /home/sebald/octave/octave/octave/doc/interpreter/

I'm not seeing much:

>> graphics_toolkit('qt');
>> geometryimages ('doc/interpreter/', 'griddata', 'eps');
>> geometryimages ('doc/interpreter/', 'griddata', 'eps');

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdb529700 (LWP 25604)]
0x00007ffff33f77e9 in glGetIntegerv () from /usr/lib/nvidia-340/libGL.so.1

probably because there is no traceable code for the video driver.  "dump", "trace"?  Is there something more I can do here?

Anyway, because of the fact all three graphics toolkits are acting strange under the same commands, my guess is the issue might lie in Octave script or plot-related C code.  The seg fault above is probably because of improper data fed to a GL function.

Dan Sebald <sebald>
Wed 04 May 2016 11:49:10 PM UTC, original submission:  

[This may be related to a few similar looking bug reports]

Apply the attached patch to make the plots using geometryimages() visible on the screen at least momentarily.  Then run:

./run-octave --path /home/sebald/octave/octave/octave/doc/interpreter/

It looks like multiple toolkits are crashing under the same circumstances:

 >> graphics_toolkit('fltk')
>> graphics_toolkit
ans = fltk
>> geometryimages ('doc/interpreter/', 'griddata', 'eps');
>> geometryimages ('doc/interpreter/', 'griddata', 'eps');
error: __osmesa_print__: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?
error: called from
     __opengl_print__ at line 172 column 7
     print at line 498 column 14
     geometryimages at line 71 column 5
>> geometryimages ('doc/interpreter/', 'griddata', 'eps');
error: __osmesa_print__: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?
error: called from
     __opengl_print__ at line 172 column 7
     print at line 498 column 14
     geometryimages at line 71 column 5

Yes, the follow-up geometryimages command in FLTK does not crash the system, just gives an error.  (I thought it was FLTK that is the default toolkit these days.)  The EPS image from above sequence looks correct.

It's Qt graphics toolkit that crashes on followup geometryimages commands but here too the EPS generated on the first pass looks fine:

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

And for gnuplot graphics toolkit:

 >> graphics_toolkit('gnuplot')
>> geometryimages ('doc/interpreter/', 'griddata', 'eps');
Qt: Session management error: None of the authentication protocols specified are supported
>> geometryimages ('doc/interpreter/', 'griddata', 'eps');
>> geometryimages ('doc/interpreter/', 'griddata', 'eps');
>> geometryimages ('doc/interpreter/', 'griddata', 'eps');

and the EPS file looks fine, but on follow-up geometry commands the graphical window no longer appears.  And I should note on the first geometryiamges command gnuplot doesn't do the multiple draws as random scaling factors.  Just the one proper image at the correct scaling.

Dan Sebald <sebald>

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by sebald (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-05-06 mtmiller Dependencies- => Depends on bugs #44478
    2016-05-06 mtmiller Open/ClosedOpen => Closed
    2016-05-05 mtmiller CategoryPlotting => Plotting with OpenGL
        StatusNone => Duplicate
    2016-05-04 sebald Attached File- => Added octave-geometryimages_djs_2016may04.diff, #37073

    Back to the top


    Powered by Savane 3.5