bugGNU Octave - Bugs: bug #44338, __osmesa_print__ fails in...


bug #44338: __osmesa_print__ fails in MXE-Octave

Submitted by:  Avinoam Kalma <avinoam>
Submitted on:  Sat 21 Feb 2015 09:27:41 PM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  3 - Low Item Group:  Incorrect Result
Status:  Wont Fix Assigned to:  None
Originator Name:  Avinoam Open/Closed:  Closed
Release:  dev Operating System:  Microsoft Windows

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)

Mon 06 Aug 2018 04:24:21 PM UTC, comment #30:

Yes, we should be using the built-in Qt capabilities now for offscreen printing.

Rik <rik5>
Project Administrator
Sun 05 Aug 2018 03:37:30 PM UTC, comment #29:

For the test code in comment #27, I now see the following with Octave 4.4.0 and a recent default on Windows:

Can this bug report be closed as fixed?

Markus M├╝tzel <mmuetzel>
Project Member
Tue 27 Feb 2018 05:44:26 PM UTC, comment #28:

@John D.: Can you check whether building using '--without-osmesa' could become the default? It would be nice to get rid of all the weirdness we have had with osmesa.

Rik <rik5>
Project Administrator
Tue 27 Feb 2018 09:20:08 AM UTC, comment #27:

The patch from bug #53196 has been verified to work on Windows and is now pushed to default.

From bug #53087, I see that using osmesa provokes hard crashes on Windows. This is the problematic call

It may thus be a good idea to build official Windows binaries "--without-osmesa".

Pantxo Diribarne <pantxo>
Project Member
Mon 19 Feb 2018 09:30:57 AM UTC, comment #26:

I posted a preliminary cset (see bug #53186) to avoid having to use osmesa as long as Qt 5.1+ is used for building Octave (which is always the case in mxe). Could someone here try to build a Windows binary with this cset applied and see if this approach works on Windows too? I think it is important to build with "--disable-system-opengl" option so that we have access to modern opengl features.

Pantxo Diribarne <pantxo>
Project Member
Fri 08 Sep 2017 05:22:42 PM UTC, comment #25:

It doesn't seem to freeze every time, however both cause the freeze (when they do). With the opengl compiled from mesa, it will allow me to attach in debug and see where it segfaulted (whether it is valid or not)

The OS version of opengl just reports the stack was corrupted when I try attaching.

using the OS's opengl (when It doesn't freeze):

- h = figure - no message

- plot (1:10, "o-") - no message

- print (h, "junk1.ps"), the file is viewable

- set (h, "visible", "off"); - no message

- print (h, "junk.ps");

It creates the file slightly smaller in size than the visible one, viewing the file, it shows as just an empty page.

using mesa opengl:

- h = figure displays warning message: couldn't open dxtn.dll, software DXTn compression/decompression unavailable

- plot (1:10, "o-") shows Mesa: User error: GL_INVALID_ENUM in glDisable(0x4008)

- print (h, "junk1.ps"), the file is viewable

- set (h, "visible", "off"); - no message

- print (h, "junk1.ps") displays:
- file shows as a blank page

On the times that it does lock up, it 0 byte file.

at least when using out mesa opengl, it was built for 64 bits, however appears to behave the same.

I have not tried a 32 bit version of octave for a while to verify if it behaves the same.

John Donoghue <lostbard>
Project Member
Fri 08 Sep 2017 02:23:58 PM UTC, comment #24:

@John: IIUC Qt loads opengl32.dll (not opengl32sw.dll contrary to what I though) and it looks like it is the use of an opengl32.dll compiled from mesa that provokes the freeze right?

I have no clue but still a few questions about mesa opengl32.dll:

  • Does a simple "plot (1:10)" (without printing and with figure visible) trigger "Error 1282 occurred in init_gl_context" with Qt? With fltk?
  • see comment #14: are we linking a 64 bit Octave to an obviously 32 bit opengl library? Does it make sense to use a 64 bits build for opengl also?
  • see comment #18: In comment #14 I see no "true" error message (the "Error 1282..." is actually a warning) so the print process should proceed when it does not freeze. Is there any .ps file created when running in the debugger ?
Pantxo Diribarne <pantxo>
Project Member
Wed 06 Sep 2017 11:58:18 AM UTC, comment #23:

Using the recompiled opengl from comment #19, with it named opengl32sw.dll, appears to display same warning and errors.

WIth it renamed as opengl32.dll, it just displays the warning and never returns from the print statement

John Donoghue <lostbard>
Project Member
Wed 06 Sep 2017 10:08:04 AM UTC, comment #22:

If I copy it to the bin directory as opengl32.dll and run _opengl_info_ in octave, it reports opengl as the mesa library. If I copy it as opengl32sw.dll, _opengl_info_ reports as the video cards opengl

John Donoghue <lostbard>
Project Member
Wed 06 Sep 2017 08:16:01 AM UTC, comment #21:

@John: is there a way to check that the opengl library we provide is actually used instead of the system opengl32.dll?

Pantxo Diribarne <pantxo>
Project Member
Tue 05 Sep 2017 09:27:38 PM UTC, comment #20:

I tried the rename to opengl32sw.dll but it didn't do anything.

It did not include llvmpipe support, but softpipe support (as llvm is not included)

I havent tried the download version but will try that.

John Donoghue <lostbard>
Project Member
Tue 05 Sep 2017 06:16:37 PM UTC, comment #19:

@John: did you try to rename opengl32.dll to opengl32sw.dll? Does this library include support for llvmpipe as explained in the link in comment #9 and does it also hold symbols related to to os-mesa? Did you try to download precompiled opengl32sw.dll from [1] and put it aside octave.exe?

[1] http://download.qt.io/development_releases/prebuilt/llvmpipe/windows/

Pantxo Diribarne <pantxo>
Project Member
Tue 05 Sep 2017 12:35:31 PM UTC, comment #18:

Comment #17: I realized that after posting :) WIth the suggested LD_PRELOAD it works for building under Linux.

Comment #9, I build a version of opengl32.dll from mesa and still get the same message occurring. Maybe it would help other issues people have has regarding video card?

If I run in the debugger, it doesn't get stuck within the print command, just prints out the warning/error messages.

John Donoghue <lostbard>
Project Member
Sat 02 Sep 2017 08:53:21 PM UTC, comment #17:

I was commenting with the reference to:

It also may have started after I updated my Linux (build) machine, where I now have to create a native build with openmesa disabled in order to compile.



Dmitri A. Sergatskov <dasergatskov>
Sat 02 Sep 2017 07:18:51 PM UTC, comment #16:

windows 64

John Donoghue <lostbard>
Project Member
Sat 02 Sep 2017 06:41:14 PM UTC, comment #15:

(comment 13):
if your Linux distribution is Fedora, you need to do
LD_PRELOAD=/usr/lib64/libGLX_mesa.so make

to build with osmesa.

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

I found that
LD_PRELOAD=/usr/lib64/libGLX_mesa.so ./run-octave
may or may not require depending on the actual graphics card.

For newish integrated Intel graphics setting renderer to
the llvmpipe with LIBGL_ALWAYS_SOFTWARE=1 may also be helpful.


Dmitri A. Sergatskov <dasergatskov>
Sat 02 Sep 2017 06:24:39 PM UTC, comment #14:

To further add, using a 64 bit octave 4.2.1, I see similar message but it does return to the prompt.

John Donoghue <lostbard>
Project Member
Sat 02 Sep 2017 06:20:55 PM UTC, comment #13:

I am suddenly seeing this issue with latest dev octave compiled 64 bit for windows.

It may have appeared after a windows update occurred, but not 100% sure since it had been a while since I had run all tests.

It also may have started after I updated my Linux (build) machine, where I now have to create a native build with openmesa disabled in order to compile.

For me using test code in comment #11,

It never returns back the prompt.

John Donoghue <lostbard>
Project Member
Fri 02 Jun 2017 04:28:41 AM UTC, comment #12:

Philip - see https://wiki.octave.org/Windows_Installer#Tweaks, specifically the following bullet item:

> Use ./configure --disable-strip-dist-files if you want to keep debug symbols in the installed binaries for debugging on Windows.
> Beware as the total Octave distribution will be > 2 GB, the max. size for an NSIS installer. Your only options are to make zip-dist or tar-dist installers.

That's the configure option that sets the STRIP_DIST_FILES variable in the Makefile so you don't have to go editing the file yourself.

Mike Miller <mtmiller>
Project Administrator
Thu 01 Jun 2017 07:37:37 PM UTC, comment #11:

Re-titling report since the tests for _osmesa_print_ now pass, even though the behavior is still busted.

New test code

The error stream I get is

Rik <rik5>
Project Administrator
Thu 01 Jun 2017 06:21:04 PM UTC, comment #10:

What "tips" section, Mike? (comment #8)

As to comment #7:

Leaving debug symbols in is as easy as changing the line (in the top of the mxe-octave Makefile)




Remember, making a binary nsis-installer (.exe) gets tricky then as the total size of all files may be > 2 GB = out of NSIS' capabilities, so only a zipdist (or is it zip-dist?) (.zip) may be possible.

My build boxes are multi-boot systems in which I can access ("mount") the Linux /home drive directly from within Windows (read-only, for security) using ext2fsd. That makes it easy to run Octave in Windows directly from the Linux drive:
As soon as mxe-octave emits "generating installer" I quit the build process (Ctrl-C); at that moment the complete installation as it would be on Windows is present in the mxe-octave/dist/octave-<date> subdir. One can directly run octave.vbs from there (no OF packages as octave-packages can't be generated on a read-only drive but that's a minor issue here).
That'll save (at least in my case) ~20 mins waiting time for the nsis-installer generating phase, + some minutes to copy the installer over, and 5-10 mins. to install or unzip Octave in Windows. Rebooting with an SSD drive takes < 1 minute.
I suppose a similar setup (w/o need for reboot) can be gotten by connecting one's /home drive to Windows-in-a-virtual-PC.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 14 Sep 2016 02:47:29 PM UTC, comment #9:

IIUC we already use software rendering on windows. Would it make sense to force windows to use MESA software rendering by providing our own opengl32sw.dll? See this: http://wiki.qt.io/Cross-compiling-Mesa-for-Windows

Pantxo Diribarne <pantxo>
Project Member
Sun 08 Mar 2015 01:48:00 PM UTC, comment #8:

I added the steps for including gdb and debug symbols to the "tips" section (or at least how I figured out how to do it).

Mike Miller <mtmiller>
Project Administrator
Sun 08 Mar 2015 12:32:14 PM UTC, comment #7:

I think the problem right now is that all the binaries are stripped of debugging symbols as part of the creation of the nsis_installer package.

Can you send your request for updating the wiki to Octave-Maintainers because only four people are watching this bug report, and I believe it will be John D. or jwe who will know enough to do that.

Rik <rik5>
Project Administrator
Sun 08 Mar 2015 09:47:47 AM UTC, comment #6:

I made some tests with the MXE-Octave build of 4.0.0-rc1 and created a DEFUN_DLD which calls gl* functions directly. This works fine but not if I call draw on opengl_renderer.

From this I guess that the problem lies in gl_render.cc and not in _osmesa_print_

Can someone update the MXE page on our wiki to describe the steps needed to build a 4.0.0-rc1 in MXE-octave with debugging symbols which also includes gdb? I tried to add gdb to $(PKG)_DEPS and ./configure FFLAGS=-g CFLAGS=-g CXXFLAGS=-g but apparently failed.

Andreas Weber <andy1978>
Project Member
Sat 07 Mar 2015 03:51:36 PM UTC, comment #5:

The OSMESA facility in Octave is of use only for printing off-screen figures with OpenGL and this happens mostly when Octave creates it's own documentation. Given that we are still restricted to using gnuplot to create the documentation anyways, and that the documentation is shipped in the distribution tarball so user's don't need to re-generate it, this problem should not be a gating item for the 4.0 release.

I pushed a cset (http://hg.savannah.gnu.org/hgweb/octave/rev/d9f6260cf20a) that disables the _osmesa_print_ tests when not running on a UNIX platform. I am leaving open the report as a reminder to eventually fix this.

Rik <rik5>
Project Administrator
Wed 04 Mar 2015 07:06:11 PM UTC, comment #4:

The integration of OSMesa in MXE-Octave is still in progress. jwe added it as target to the MXE-Octave and osmesa.dll is built but as far that I know, no one got it to work in windows so far.

Btw, I'm running the MXE build in a virtualbox with Windows XP and doesn't see the "couldn't open dxtn.dll"

Andreas Weber <andy1978>
Project Member
Fri 27 Feb 2015 06:10:31 PM UTC, comment #3:

I changed this bug to depend on bug #44360. There is something incorrect in the _osmesa_print_ tests.

Rik <rik5>
Project Administrator
Wed 25 Feb 2015 01:14:49 AM UTC, comment #2:

Here is a simpler test run

Note that when running _osmesa_print_ twice, the second time kills the plot figure.

Rik <rik5>
Project Administrator
Tue 24 Feb 2015 05:58:43 AM UTC, comment #1:

Confirmed, now that I can build MXE-octave again. I don't think the warning message is part of the problem. It really does seem to be related to lack of support for a proprietary encoding format (http://lists.qt-project.org/pipermail/development/2013-August/012397.html).

However, the incorrect viewport error from gl2ps seems to be the heart of the problem. We used to specify the viewport, and recently we changed to use the default viewport. That might be related.

It's probably not terrifically important to fix this before the release as offscreen printing is only used to generate the figures for the documentation and that has already been done in the tarball that MXE-octave uses to build from.

Rik <rik5>
Project Administrator
Sat 21 Feb 2015 09:27:41 PM UTC, original submission:
Avinoam Kalma <avinoam>
Project Member


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

Attach Files:

No files currently attached


   bug dependencies.

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by philipnienhuis
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by avinoam (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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-08-06 rik5 StatusPostponed => Wont Fix
        Open/ClosedOpen => Closed
    2017-06-01 rik5 Summary test _osmesa_print_.cc-tst fails in MXE-octave => _osmesa_print_ fails in MXE-Octave
    2017-06-01 philipnienhuis Carbon-Copy- => Added philipnienhuis
    2016-07-21 mtmiller Dependencies- => bugs #48583 is dependent
    2016-05-13 mtmiller Dependencies- => bugs #47907 is dependent
    2015-03-07 mtmiller Priority5 - Normal => 3 - Low
        StatusConfirmed => Postponed
    2015-02-27 rik5 Dependencies- => Depends on bugs #44360
    2015-02-24 rik5 StatusNone => Confirmed

    Back to the top

    Powered by Savane 3.3