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

 
 

bug #44338: __osmesa_print__ fails in MXE-Octave

Submitter:  Avinoam Kalma <avinoam>
Submitted:  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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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:

error: No functional osmesa


Can this bug report be closed as fixed?

Markus Mützel <mmuetzel>
Group administrator
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>
Group 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


plot (1:10)
try
  a = __osmesa_print__ (gcf);
catch
  error ("No functional osmesa")
end


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

Pantxo Diribarne <pantxo>
Group 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>
Group 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");

Mesa warning: couldn't open dxtn.dll, software DXTn compression/decompression unavailable
GL2PS error: Incorrect viewport (x=0, y=198844792, width=0, height=198790600)
error: gl2ps_renderer::draw: gl2psBeginPage returned GL2PS_ERROR
error: called from
    __opengl_print__ at line 161 column 7
    print at line 521 column 14



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:

Mesa warning: couldn't open dxtn.dll, software DXTn compression/decompression unavailable
GL2PS error: Incorrect viewport (x=0, y=493109624, width=0, height=493108952)
error: gl2ps_renderer::draw: gl2psBeginPage returned GL2PS_ERROR
error: called from
    __opengl_print__ at line 161 column 7
    print at line 521 column 14

- 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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.
--

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

windows 64

John Donoghue <lostbard>
Group 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.

Similarly,
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.
--

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.


>> print (h, "junk.ps");
Mesa warning: couldn't open dxtn.dll, software DXTn compression/decompression unavailable
warning: opengl_renderer: Error 1282 occurred in init_gl_context
warning: called from
    __opengl_print__ at line 172 column 7
    print at line 519 column 14
warning: opengl_renderer: Error 1282 occurred drawing 'text' object
warning: called from
    __opengl_print__ at line 172 column 7
    print at line 519 column 14


John Donoghue <lostbard>
Group 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,


>> print (h, "junk.ps");
Mesa warning: couldn't open dxtn.dll, software DXTn compression/decompression unavailable
warning: opengl_renderer: Error 'invalid operation' (1282) occurred in init_gl_context
warning: called from
    __opengl_print__ at line 161 column 7
    print at line 521 column 14



It never returns back the prompt.

John Donoghue <lostbard>
Group 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>
Group Member
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


h = figure;
plot (1:10, "o-");
set (h, "visible", "off");
print (h, "junk.ps");


The error stream I get is


Mesa warning: couldn't open dxtn.dll, software DXTn compression/decompression unavailable
warning: opengl_renderer: Error 'invalid operation' (1282) occurred in init_gl_context
warning: called from
    __opengl_print__ at line 172 column 7
    print at line 520 column 14
warning: opengl_renderer: Error 'invalid operation' (1282) occurred drawing 'text' object
warning: called from
    __opengl_print__ at line 172 column 7
    print at line 520 column 14
warning: opengl_renderer: Error 'invalid operation' (1282) occurred drawing 'text' object
warning: called from
    __opengl_print__ at line 172 column 7
    print at line 520 column 14
warning: opengl_renderer: Error 'invalid operation' (1282) occurred drawing 'text' object
warning: called from
    __opengl_print__ at line 172 column 7
    print at line 520 column 14
warning: opengl_renderer: Error 'invalid operation' (1282) occurred drawing 'line' object
warning: called from
    __opengl_print__ at line 172 column 7
    print at line 520 column 14
warning: gl2ps_renderer::draw_axes: empty feedback buffer and/or nothing else to print
warning: called from
    __opengl_print__ at line 172 column 7
    print at line 520 column 14
warning: opengl_renderer: Error 'invalid operation' (1282) occurred drawing 'axes' object
warning: called from
    __opengl_print__ at line 172 column 7
    print at line 520 column 14
warning: opengl_renderer: Error 'invalid operation' (1282) occurred drawing 'figure' object
warning: called from
    __opengl_print__ at line 172 column 7
    print at line 520 column 14



Rik <rik5>
Group 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)
 
STRIP_DIST_FILES := yes

into

STRIP_DIST_FILES := no

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>
Group 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>
Group 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>
Group Member
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>
Group 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>
Group 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>
Group 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>
Group 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>
Group administrator
Wed 25 Feb 2015 01:14:49 AM UTC, comment #2: 

Here is a simpler test run


>> h = figure
h =  1
>> plot (1:10)
>> plot (1:10, 'o-')
>> __osmesa_print__ (h, "junk.ps", "ps")
Mesa warning: couldn't open dxtn.dll, software DXTn compression/decompression unavailable
warning: gl2ps-renderer::draw: empty feedback buffer and/or nothing else to print
>> __osmesa_print__ (h, "junk.ps", "ps")
Mesa warning: couldn't open dxtn.dll, software DXTn compression/decompression unavailable
GL2PS error: Incorrect viewport (x=-1, y=0, width=0, height=-1)
error: gl2ps-renderer::draw: gl2psBeginPage returned GL2PS_ERROR


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


Rik <rik5>
Group 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>
Group administrator
Sat 21 Feb 2015 09:27:41 PM UTC, original submission:  



>> test __osmesa_print__.cc-tst
Mesa warning: couldn't open dxtn.dll, software DXTn compression/decompression unavailable
GL2PS error: Incorrect viewport (x=0, y=1072693248, width=0, height=0)
***** testif HAVE_OSMESA
 h = figure ("visible", "off");
 fn = tempname ();
 sombrero ();
 __osmesa_print__ (h, fn, "svg");
 assert (stat (fn).size, 2692270, -0.1);
 unlink (fn);
 img = __osmesa_print__ (h);
 assert (size (img), [get(h, "position")([4, 3]), 3])
 ## Use pixel sum per RGB channel as fingerprint
 img_fp = squeeze (sum (sum (img), 2));
 assert (img_fp, [52942515; 54167797; 56158178], -0.05);
!!!!! test failed
gl2ps-renderer::draw: gl2psBeginPage returned GL2PS_ERROR


Avinoam Kalma <avinoam>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group 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.13-cf05.
    Corresponding source code