bugGNU Octave - Bugs: bug #50479, __osmesa_print__ fails with mesa...

 
 

bug #50479: __osmesa_print__ fails with mesa using libglvnd, build and test suite fail

Submitted by:  Michael Godfrey <godfrey>
Submitted on:  Tue 07 Mar 2017 01:34:01 PM UTC  
 
Category: Configuration and Build SystemSeverity: 4 - Important
Priority: 5 - NormalItem Group: Regression
Status: ConfirmedAssigned to: None
Originator Name: godfreyOpen/Closed: Open
Release: devOperating 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 Jump to the original submission)

Tue 07 Nov 2017 05:09:23 AM UTC, comment #39:

Open an "issue" at https://github.com/NVIDIA/libglvnd/issues ?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 07 Nov 2017 04:57:17 AM UTC, comment #38:

On a system with libglvnd, if you start Octave with

set in the environment, then try to print with osmesa, for example, with

you should see the following error messages:

If I understand correctly, those first two messages about calling an OpenGL function without a current context are coming from the calls to glGetIntegerv in F__osmesa_print__ and are happening because of the way libglvnd handles dispatching.

It worked previously if you were using a Mesa libGL because we linked directly to libGL and OpenGL functions were provided directly from there. Since OSMesa uses a context that begins with the base Mesa context, those gl* calls would work.

Now, there is some magic in libglvnd to manage the pointer to the OpenGL context and dispatch to fucntions that properly manage that context. This works for libGL, but not libOSMesa. So when glGetIntegerv is called no context has been created and you end up in the stub function that reports the error.

Note that making the figure visible so that a Mesa context is created does not work. The following still fails with the same error message:

still fails with the same messages because although OSMesaMakeCurrent would make the context current when using the Mesa libGL, it does not do that with libglvnd so the libglvnd context is still invalid.

To fix this, it seems we need to have libOSMesa integrated with libglvnd so that the OSMesa context and dispatching for functions in libOSMesa can be properly managed by libglvnd.

It would be great if we could just ask libglvnd to create an off-screen rendering context that uses OSMesa and have it manage the function dispatch. This should allow OSMesa to mix with any vendor OpenGL library, not just Mesa.

I've spent considerable time looking at this problem but it's still not clear to me exactly how to do that. It appears that libglvnd maintains a table of OpenGL contexts and dispatching info for libGL functions that is indexed by X11 display and screen info. For OSMesa, there may not be a display or screen, so some other way of storing and indexing these contexts is needed.

John W. Eaton <jwe>
Project Administrator
Fri 08 Sep 2017 08:53:26 PM UTC, comment #37:

This bug now also affects Debian unstable with the introduction of Mesa 17.2.0 and its new dependence on libglvnd.

Same workaround works on Debian unstable:

Without the LD_PRELOAD make all fails building the images under doc/interpreter and make check fails on tests that produce off-screen figures.

Using LD_PRELOAD does not seem like a solution to me.

Mike Miller <mtmiller>
Project Administrator
Mon 07 Aug 2017 01:43:48 PM UTC, comment #36:

The fix for #51631 does affect this bug on Fedora 26.
Running without:
export LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0.0.0
make check completes but reports 4 FAILs
libinterp/dldfcn/__osmesa_print__.cc-tst .................... PASS 0/2
FAIL 2
and
publish.tst ................................................. PASS 0/2
FAIL 2

Running with:
export LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0.0.0
make check completes with 0 FAILS.

Michael Godfrey <godfrey>
Project Member
Fri 30 Jun 2017 10:48:24 PM UTC, comment #35:

Just for information the bash command on Fedora 25 is:
export LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0.0.0

Michael Godfrey <godfrey>
Project Member
Sat 08 Apr 2017 10:08:50 PM UTC, comment #34:

The library that is known as libGLX_mesa on Fedora is just libGL on Debian and Ubuntu distros, which is probably why this workaround isn't needed. Fedora decided to build mesa with support for the new glvnd dispatch library. Someone will have to figure out what this means for Octave's on-screen GL and off-screen OSMesa support.

Mike Miller <mtmiller>
Project Administrator
Sat 08 Apr 2017 04:33:47 PM UTC, comment #33:

Dmitri's workaround does work for me too. Is there
a more general way to fix this? Or, should this
workaround be integrated in the startup?

And, the build of the documentation still fails.

My glxinfo |grep -i mesa is:

Michael Godfrey <godfrey>
Project Member
Sat 08 Apr 2017 09:02:50 AM UTC, comment #32:

This could be related:

https://lists.freedesktop.org/archives/mesa-users/2016-August/001197.html

Dmitri A. Sergatskov <dasergatskov>
Sat 08 Apr 2017 08:56:57 AM UTC, comment #31:

It looks to me that the issue is osmesa conflicts with some other
mesa libs. The only workaround I found it to
LD_PRELOAD==/usr/lib64/libGLX_mesa.so.0.0.0
prior to running octave.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Sat 08 Apr 2017 08:43:21 AM UTC, comment #30:

The test for depth_bits and stencil_bits was a clumsy attempt to check if the OSMesa stuff is working. The code before the test tries to set depth and stencil bits to 16 and 0 and if the readed values matches I thought this would be an indication that something goes wrong...

After all, if you disable the test (comment the lines) is osmesa working for you?

You wrote that GL_DEPTH_BITS is "54" on your system which looks to me that this is just a value read from the wrong memory address due to incompatible libraried.

Also make sure that you are using a Mesa based GPU driver.

Andreas Weber <andy1978>
Project Member
Sat 08 Apr 2017 01:45:28 AM UTC, comment #29:

I looked at this a bit and edited _osomesa_print_.cc:

if (z != 16 || s != 0)
error ("__osmesa_print__: Depth and stencil doesn't match,"
" are you sure you are using OSMesa >= 9.0? GL_DEPTH_BITS \"%i\" GL_STENCIL_BITS \"%i\"", z, s);
and ran this and got:
error: _osmesa_print_: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0? GL_DEPTH_BITS "54" GL_STENCIL_BITS "0"

So, GL_DEPTH_BITS = 54 is the problem.

Michael Godfrey <godfrey>
Project Member
Sat 08 Apr 2017 12:04:21 AM UTC, comment #28:

This error is, of course, due to the
GL_DEPTH_BITS and
GL_STENCIL_BITS
in the latest osmesa. The test that fails is
at line 145 of --osmesa_print__.cc
someone with osmesa knowledge is needed to fix this.
Owner: Copyright (C) 2016-2017 Andreas Weber <andy.weber.aw@gmail.com>

Michael Godfrey <godfrey>
Project Member
Thu 06 Apr 2017 05:08:24 PM UTC, comment #27:

Finally, here is what confused my make install:
With the current build it is necessary to run
make -i install
This has the side effect of leaving a large number of
files with owner root. This then prevents subsequent
makes from functioning "correctly".

So, the remaining problem is as originally stated:

error: osmesa_print: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?

Michael Godfrey <godfrey>
Project Member
Tue 04 Apr 2017 02:04:51 AM UTC, comment #26:

My previous entry is not quite accurate. I just did
a clean build and the failure due to osmesa version has
returned as Dmitri reported. For the build to complete
I had to do: make -i and no documentation was generated
in doc/interpreter.

But, if I run:
./run-octave --no-gui
randn("state",1);
hist(randn (10000,1),30)
graphics_toolkit
ans = fltk
========================
I get a correct histogram as I did with the previous system.
And, as before print xxhist.pdf produces the diagonal lines.
So, now I have no explanation of how my build system
started to complete using gnuplot.

Michael Godfrey <godfrey>
Project Member
Mon 03 Apr 2017 03:37:13 AM UTC, comment #25:

I just run ./configure
and I did a clean rebuild recently.
It appeared that this was what fixed it for me. But,...

The unexplained behavior is that I have osmesa and the
build uses it, and that works, but the build of the
/doc/interpreter stuff uses gnuplot!!!
I think that there was a change in the build script
to use gnuplot even though osmesa and everything that
fltk and qt needs are available.

However, this does not explain Dmitri's problem.

Michael Godfrey <godfrey>
Project Member
Mon 03 Apr 2017 03:20:49 AM UTC, comment #24:

Did you run
./configure --without-osmesa

?

Remove your build tree, re-sync and re-build.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 03 Apr 2017 03:12:23 AM UTC, comment #23:

Also,
On my system:
[godfrey@pbdsl4 octave]$ rpm -qa|grep -i osmesa
399:mesa-libOSMesa-devel-13.0.4-3.fc25.x86_64
2487:mesa-libOSMesa-13.0.4-3.fc25.x86_64
[godfrey@pbdsl4 octave]$

Michael Godfrey <godfrey>
Project Member
Mon 03 Apr 2017 03:09:04 AM UTC, comment #22:

Mike,
In my installed octave I get:
octave:1> _have_feature_ ("OSMESA")
ans = 1
octave:2>

But, the build switches to gnuplot...

Michael Godfrey <godfrey>
Project Member
Mon 03 Apr 2017 03:02:16 AM UTC, comment #21:

Michael - what does

return in your current build of Octave? If it returns false, then the build will automatically switch to gnuplot for building the plot images under doc/interpreter.

Mike Miller <mtmiller>
Project Administrator
Mon 03 Apr 2017 02:23:30 AM UTC, comment #20:

Dimitri,

OK. Here is what I get:

octave:1> randn("state",1);
octave:2> hist(randn (10000,1),30)
octave:3> graphics_toolkit
ans = fltk
octave:4> print histxx.pdf
octave:5> graphics_toolkit
ans = fltk
=========================
The displayed plot is OK.
The result of print histxx.pdf shows the diagonal
lines.

So, it appears that the build uses gnuplot at least
for some of the plots (some fail with gnuplot).

It was not a good idea to make the build dependent on gnuplot.
It would be really useful if this could be cleaned up.
But, of course, plotting has always been a major problem area.

Michael Godfrey <godfrey>
Project Member
Mon 03 Apr 2017 02:12:14 AM UTC, comment #19:

Interesting. I did not switch. Something in the
build scripts made that choice. I will try the histogram
outside of the build. My .octaverc selects fltk.

Michael Godfrey <godfrey>
Project Member
Mon 03 Apr 2017 12:50:51 AM UTC, comment #18:

Your file is created by gnuplot:

pdfinfo hist.pdf
Title: /tmp/oct-D5dEHe.eps
Subject: gnuplot plot
Author: godfrey
Creator: gnuplot 5.0 patchlevel 5
Producer: GPL Ghostscript 9.20
CreationDate: Thu Mar 30 13:12:06 2017
ModDate: Thu Mar 30 15:12:06 2017 CDT
Tagged: no
UserProperties: no
Suspects: no
Form: none
JavaScript: no
Pages: 1
Encrypted: no
Page size: 360 x 252 pts
Page rot: 0
File size: 6711 bytes
Optimized: no
PDF version: 1.5

Mine created by ftgl:
pdfinfo hist.pdf
Title: gl2ps_renderer figure
Author: Octave
Creator: GL2PS 1.3.9, (C) 1999-2015 C. Geuzaine
Producer: GPL Ghostscript 9.20
CreationDate: Sun Apr 2 19:49:21 2017 CDT
ModDate: Sun Apr 2 19:49:21 2017 CDT
Tagged: no
UserProperties: no
Suspects: no
Form: none
JavaScript: no
Pages: 1
Encrypted: no
Page size: 360 x 252 pts
Page rot: 0
File size: 4286 bytes
Optimized: no
PDF version: 1.5

Somehow you switched to using gnuplot as the default backend.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 03 Apr 2017 12:46:18 AM UTC, comment #17:

Dmitri,
You might check the time stamp on your hist.pdf.
The error that you are getting will, I think, prevent it
from being created by the build that fails.

Michael Godfrey <godfrey>
Project Member
Mon 03 Apr 2017 12:36:36 AM UTC, comment #16:

My hist.pdf is attached.
And, my hg id matches your.

Looking quickly, your system seems much like mine.
The hardware is surely different but hard to see why that
would matter.

(file #40239)

Michael Godfrey <godfrey>
Project Member
Mon 03 Apr 2017 12:23:54 AM UTC, comment #15:

Also:

rpm -qa | grep mesa
mesa-libGLw-8.0.0-8.fc24.x86_64
mesa-libGLES-13.0.4-3.fc25.x86_64
mesa-libEGL-13.0.4-3.fc25.x86_64
mesa-libGLw-devel-8.0.0-8.fc24.x86_64
mesa-libGLU-9.0.0-10.fc24.x86_64
mesa-libEGL-devel-13.0.4-3.fc25.x86_64
mesa-libglapi-13.0.4-3.fc25.x86_64
mesa-libGLES-devel-13.0.4-3.fc25.x86_64
mesa-libwayland-egl-devel-13.0.4-3.fc25.x86_64
mesa-filesystem-13.0.4-3.fc25.x86_64
mesa-libxatracker-13.0.4-3.fc25.x86_64
mesa-libGL-13.0.4-3.fc25.x86_64
mesa-libgbm-devel-13.0.4-3.fc25.x86_64
mesa-libgbm-13.0.4-3.fc25.x86_64
mesa-libGL-devel-13.0.4-3.fc25.x86_64
mesa-libGLU-devel-9.0.0-10.fc24.x86_64
mesa-libxatracker-devel-13.0.4-3.fc25.x86_64
mesa-dri-drivers-13.0.4-3.fc25.x86_64
mesa-libwayland-egl-13.0.4-3.fc25.x86_64
mesa-vulkan-drivers-13.0.4-3.fc25.x86_64
mesa-libOpenCL-devel-13.0.4-3.fc25.x86_64
mesa-libOSMesa-devel-13.0.4-3.fc25.x86_64
mesa-libd3d-devel-13.0.4-3.fc25.x86_64
mesa-libd3d-13.0.4-3.fc25.x86_64
mesa-libOSMesa-13.0.4-3.fc25.x86_64
mesa-libOpenCL-13.0.4-3.fc25.x86_64

....

make[2]: Entering directory '/home/dima/src/octave/gcc_default'
GEN etc/icons/octave-logo-256.png
GEN etc/icons/octave-logo-48.png
GEN etc/icons/octave-logo-32.png
GEN etc/icons/octave-logo-16.png
TEXI2PDF doc/liboctave/liboctave.pdf
PDFTEX doc/refcard/refcard-a4.pdf
PDFTEX doc/refcard/refcard-legal.pdf
PDFTEX doc/refcard/refcard-letter.pdf
GEN etc/icons/octave-logo-512.png
GEN etc/icons/octave-logo-128.png
GEN etc/icons/octave-logo-64.png
GEN etc/icons/octave-logo-24.png
GEN etc/icons/octave-logo-22.png
GEN etc/icons/octave-logo.ico
GEN doc/interpreter/voronoi.eps
GEN doc/interpreter/triplot.eps
GEN doc/interpreter/griddata.eps
GEN doc/interpreter/convhull.eps
error: _osmesa_print_: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?
Makefile:27871: recipe for target 'doc/interpreter/triplot.eps' failed
make[2]: *** [doc/interpreter/triplot.eps] Error 1
make[2]: *** Waiting for unfinished jobs....
error: _osmesa_print_: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?
Makefile:27875: recipe for target 'doc/interpreter/convhull.eps' failed
make[2]: *** [doc/interpreter/convhull.eps] Error 1
error: _osmesa_print_: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?
<...etc...>

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 03 Apr 2017 12:10:31 AM UTC, comment #14:

yes and yes.
hg id
68dbde0e670a tip @

Could you send me yours hist.pdf?

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Sun 02 Apr 2017 10:55:04 PM UTC, comment #13:

Dmitri,

Are you using Fedora 25 with latest updates, or
equivalent? And, mesa libraries at 13.0.4-3?

Of course, it may have been something else that
fixed the problem for me...

And, are you using latest Octave updates?

Yes, 15.2 is the histogram. I suspect that it is an
Octave fix that fixed this, so check that you have
latest Octave fixes.

Michael Godfrey <godfrey>
Project Member
Sun 02 Apr 2017 08:05:35 PM UTC, comment #12:

I still have to LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0 priot to make and the histogram pdf (I assume this is the Figure 15.2) still has diagonal dashed lines inside the bars (attached).

Dmitri.

(file #40236)

Dmitri A. Sergatskov <dasergatskov>
Sun 02 Apr 2017 06:32:37 PM UTC, comment #11:

I have not seen a patch which fixed this problem,
but as of recent Fedora updates the problem is,
for me, gone.

So, if this was just a Fedora transient, the report
can be closed.

And, separately, the Figure 15.2 now displays
correctly! This must have been fixed by one of the
recent plotting code updates. (This is using FLTK.)

Michael Godfrey <godfrey>
Project Member
Wed 22 Mar 2017 05:27:04 PM UTC, comment #10:

It would be best to fix this bug so that users can use
print with visible off while using the osmesa dependent
graphics_toolkits. This would also fix the documentation
build problem. Users face the same problem as the build
when using scripts tp generate many plots: having each plot
pop up on the screen is not usually helpful.

Falling back to gnuplot is not a good choice either for
system build of for users.

Michael Godfrey <godfrey>
Project Member
Wed 22 Mar 2017 07:44:20 AM UTC, comment #9:

One workaround is to do

LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0 make

(and
LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0 make check
)

Could the same be achieved by changing linking order
(in the Makefile)?

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Tue 21 Mar 2017 07:02:48 PM UTC, comment #8:

The build uses "visible" = "off" so that plots do not pop up on the user's display while building Octave. Building the figures for the manual is part of the (maintainer) build, and it was decided that it should not open new windows or move focus away from the terminal or from anything else the user might be doing while the build is running.

Building without OSMesa (--without-osmesa) or without OpenGL (--without-opengl) forces the doc/interpreter build rules to drop back to using gnuplot to generate the figures for the manual.

Mike Miller <mtmiller>
Project Administrator
Mon 20 Mar 2017 09:27:07 AM UTC, comment #7:

Dmitri,

Correct, but many scripts are set to use "visible off"
since there was an extended period when only this worked.
This is why the build uses "visible off". And, there must
have been a time when osomega was needed with visible off,
but there also was a time when this was not true.

Still a bug worth fixing. But, it appears to be an osomega
problem. Someone with more knowledge of osomega is needed
to find where/how it can be fixed.

Michael Godfrey <godfrey>
Project Member
Mon 20 Mar 2017 01:27:42 AM UTC, comment #6:

I thought osmesa only needed if you want to produce prints w/o
actual plot (on a headless server e.g.).
A more common plot/print sequence seems to work fine...

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Mon 20 Mar 2017 12:06:07 AM UTC, comment #5:

I should have added that plots work, but print does
not. Thus, no .pdf files can be generated for example.

Michael Godfrey <godfrey>
Project Member
Mon 20 Mar 2017 12:03:42 AM UTC, comment #4:

This error also affects the 4.0.3 release on Fedora 25
if Fedora has been updated to current osmesa. So, it is
more serious.

Michael Godfrey <godfrey>
Project Member
Sun 12 Mar 2017 12:34:06 PM UTC, comment #3:

I get the same under Arch Linux. We recently got an update of the mesa infrastructure similar to the one Fedora got.

Stefan Husmann <haawda>
Tue 07 Mar 2017 08:41:24 PM UTC, comment #2:

It is the same error message we have on ubuntu 14.04.2: see https://bugs.launchpad.net/ubuntu/trusty/+source/mesa/+bug/1424059

Pantxo Diribarne <pantxo>
Project Member
Tue 07 Mar 2017 03:49:54 PM UTC, comment #1:

I can confirm that.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Tue 07 Mar 2017 01:34:01 PM UTC, original submission:

After recent update of Fedora 25 I get during build:
error: _osmesa_print_: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?

The current mesa version is: 13.0.4-1

Michael Godfrey <godfrey>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #40239:  hist.pdf added by godfrey (7KiB - application/pdf)
file #40236:  hist.pdf added by dasergatskov (4KiB - application/pdf)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by andy1978 (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by haawda (Posted a comment)
  • -unavailable- added by pantxo (Posted a comment)
  • -unavailable- added by dasergatskov (Posted a comment)
  • -unavailable- added by godfrey (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 08 Sep 2017 09:00:30 PM UTCmtmillerSeverity3 - Normal=>4 - Important
      Summarybuild fails on osmesa print=>_osmesa_print_ fails with mesa using libglvnd, build and test suite fail
    Mon 03 Apr 2017 12:36:36 AM UTCgodfreyAttached File-=>Added hist.pdf, #40239
    Sun 02 Apr 2017 08:05:35 PM UTCdasergatskovAttached File-=>Added hist.pdf, #40236
    Tue 07 Mar 2017 08:41:54 PM UTCpantxoStatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup1