bugGNU Octave - Bugs: bug #47337, [Windows] fltk toolkt: infinite...

 
 

bug #47337: [Windows] fltk toolkt: infinite loop "GL2PS warning: Unknown token in buffer" when printing

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Fri 04 Mar 2016 11:23:33 AM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  philipnienhuis 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

Sun 22 Oct 2017 06:32:04 PM UTC, comment #42: 

The good news is that with the mesa-based opengl32.dll (in <mxe-octave>/bin, next to octave-gui.exe et al), see here:
http://hg.octave.org/mxe-octave/rev/8f9bee27223f
this bug doesn't happen anymore.
When switching to the system opengl32.dll the bug comes back. So this indeed is a HW-driver based problem.

Closing as "fixed"

Philip Nienhuis <philipnienhuis>
Group Member
Sun 27 Aug 2017 04:38:59 AM UTC, comment #41: 
Avinoam Kalma <avinoam>
Group Member
Sat 26 Aug 2017 04:31:21 PM UTC, comment #40: 

How new is your MXE cross-build?  It has to be newer than cb8251337689 which was committed on Aug. 9th.

Rik <rik5>
Group administrator
Sat 26 Aug 2017 06:49:06 AM UTC, comment #39: 

There is no error when running the commands from comment #38,
but a.ps is empty.

Avinoam Kalma <avinoam>
Group Member
Sat 26 Aug 2017 12:28:28 AM UTC, comment #38: 

Could this somehow be related to fonts and font rendering?

You will need a fairly new dev tip for this to work, but try


graphics_toolkit fltk
plot (1:10)
set (gca, "visible", "off")
print a.ps


The code plots the simplest possible OpenGL object, a line, and then turns off everything else (ticks, tick labels, etc.).

Rik <rik5>
Group administrator
Mon 21 Aug 2017 01:13:01 PM UTC, comment #37: 

It could be gl2ps, but it can also be another error on the OpenGL code. Or an OpenGL related dependency update.

In 2016 I've been bisecting to find out which cset introduced this behavior; I had several older mxe builds lying around to help me there (I usually make & use a new build twice a week or so). But I abandoned that in the summer of 2016 due to lack of time, and because I deleted a lot of old builds that I saw no more use for to conserve disk space.

AFAICS the cset (if a cset is at fault at all) must be from somewhere late 2015 (fall or winter).

Note that not only core Octave was updated in mxe-octave - several other dependencies have been updated as well in the period fall 2015 - spring 2016.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 19 Aug 2017 09:14:33 PM UTC, comment #36: 

Writing svg file produce the same error

The setenv("LIBGL_ALWAYS_SOFTWARE", "1") does not help either.

Avinoam Kalma <avinoam>
Group Member
Sat 19 Aug 2017 12:06:03 AM UTC, comment #35: 

Another test is to set LIBGL_ALWAYS_SOFTWARE=1 either before
starting octave or from withing octave before the first plot.


LIBGL_ALWAYS_SOFTWARE=1 octave


or (at octave prompt)


octave:1> setenv("LIBGL_ALWAYS_SOFTWARE", "1")
octave:2> graphics_toolkit fltk
octave:3> plot (1:10)
octave:4> print a.ps


Dmitri
--

Dmitri A. Sergatskov <dasergatskov>
Fri 18 Aug 2017 11:41:24 PM UTC, comment #34: 

Do you get the error if you print to svg file?

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Fri 18 Aug 2017 08:31:59 PM UTC, comment #33: 

gl2ps version is 1.4

Avinoam Kalma <avinoam>
Group Member
Fri 18 Aug 2017 07:45:08 PM UTC, comment #32: 

What is the version of gl2ps?

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Fri 18 Aug 2017 07:41:07 PM UTC, comment #31: 

This problem still exists in dev version, again, on a machine with Intel card

Avinoam Kalma <avinoam>
Group Member
Sat 15 Oct 2016 06:50:26 PM UTC, comment #30: 

Is it possible to build GL2PS in debug mode to find the cause of this problem, or any other way to debug this?
I have tried bisection, but could not build some old versions of Octave, and gave up.

Avinoam Kalma <avinoam>
Group Member
Fri 09 Sep 2016 12:37:05 PM UTC, comment #29: 

Avinoam, that fits well with comment #14.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 09 Sep 2016 08:15:26 AM UTC, comment #28: 

@Philip:
The machine which did not fail has Nvidia graphics card. All the other (which failed) have Intel card. Interesting...

Avinoam Kalma <avinoam>
Group Member
Wed 07 Sep 2016 07:17:26 PM UTC, comment #27: 

@Avinoam:
which ones have Intel, which ones have other graphics HW?

Panxto, comment #24:
I started "bisecting" in the sense that I have older mxe builds archived, the oldest one from Oct. 2015. But I ran out of time and have not priority for this until after maybe 4.2.0-rc1.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 06 Sep 2016 08:26:00 PM UTC, comment #26: 

I have checked this problem on 4 computers, 3 with Win-7 and
one Win-10. In one of the Win-7 machines, everything was OK,
but other 3 computers suffered from this bug.

Avinoam Kalma <avinoam>
Group Member
Thu 25 Aug 2016 01:31:23 PM UTC, comment #25: 



>> graphics_toolkit fltk
>> plot (1:10)
>> print a.ps
GL2PS warning: Unknown token in buffer


On Win-7 and Win-10. I have some Intel graphics card.
(Using Octave 4.0.3 there is no problem in my computer).

Avinoam Kalma <avinoam>
Group Member
Thu 25 Aug 2016 12:09:21 PM UTC, comment #24: 

@Avinoam: Is annotation the only place where you see the bug? Does the simpler example from comment #4 also trigger the bug? If so what is the minimal example, can you test "axes ()" instead of "plot (1:10)"? What is your graphics hardware?

We still also need a bisect to find out what cset is responsible for the regression. I'd start before the introduction of multiple viewports:

changeset:   20603:d30fc2c11455
summary:     Fix missing legend background in gl2ps outputs (bug #44765)


Pantxo Diribarne <pantxo>
Group Member
Thu 25 Aug 2016 09:21:58 AM UTC, comment #23: 

using the commands


demo annotation 1
print a.ps


on Win-10, Octacve 4.1.0+ (changeset 0ca341841198) 32 bit,
shows the same behavior described in comment #21:


warning: gl2ps_renderer::draw_axes: empty feedback buffer and/or nothing else to print
warning: called from
    __opengl_print__ at line 169 column 7
    print at line 499 column 14
GL2PS warning: Unknown token in buffer
GL2PS warning: Unknown token in buffer
GL2PS warning: Unknown token in buffer
....


Avinoam Kalma <avinoam>
Group Member
Tue 09 Aug 2016 12:01:49 AM UTC, comment #22: 

I just tested this and it works for me on my Windows XP virtual machine.  I used the test code from comment #1.


close all
graphics_toolkit ("fltk");
hf = figure ();
sombrero ();
print toto.svg


This was with cset a8a9c275e12d from 8/8/16 crossbuilt with MXE.

But, if it is a HW-related problem then we need a way to force FLTK, or OpenGL, to use a software renderer.  This capability is necessary to implement the --softwareopengl option anyways.

Rik <rik5>
Group administrator
Sat 02 Jul 2016 06:28:06 PM UTC, comment #21: 

Trying on Win 10 on my laptop, the "GL2PS warning: Unknown token in buffer" message still shows up with fltk. In addition, Octave takes ages and ages to get back to the command prompt.
In fact I had to kill it using task mgr.


Philip Nienhuis <philipnienhuis>
Group Member
Sat 02 Jul 2016 05:52:25 PM UTC, comment #20: 

Two days ago I made a new io pkg release (still in release tracker) and didn't meet any problems. But that is on my desktop (with NVidia gr.HW).
I'll try my laptop (Intel gr. HW) tonight.


Philip Nienhuis <philipnienhuis>
Group Member
Sat 02 Jul 2016 05:17:59 PM UTC, comment #19: 

@Philip: Could you test with a new development tip to see whether FLTK still has a problem?  Even if it does, we can probable demote this bug for the 4.2 release since Qt works.

Rik <rik5>
Group administrator
Fri 11 Mar 2016 07:49:57 PM UTC, comment #18: 

Running a test 4.1.0+ cross-build from Oct 17, 2015, still installed on my desktop, over the LAN on my laptop I see no problems.
Sure enough, trying the same with today's dev build shows the bug so I assume this check works.

So that would imply that somewhere between Oct 17 en Dec. 9 some change made this bug show up. Could also be in mxe-octave (newer fltk version, whatever).

(Don't worry I do not rule out HW problems. It's just that I'm curious what change uncovered the bug in that case)

Philip Nienhuis <philipnienhuis>
Group Member
Fri 11 Mar 2016 07:26:34 PM UTC, comment #17: 

Sure, crossed my mind as well, but I still wonder why:
- stable Octave (incl. rc4; built with the same mxe-octave) is not affected
- it only occurs in Windows
- it only shows up in fltk.

I'll start re-making more ancient Octave versions with mxe, starting with e.g. a year ago; there's no hurry to sort this out quickly as qt works fine. Given that stable Octave is OK I hope I am not too naive to surmise that some past version of dev Octave might not be affected.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 11 Mar 2016 06:26:48 PM UTC, comment #16: 

I'm sorry to say, but my guess is that this is hardware related.  We have had osmesa crash with certain versions of the Nvidia chipset and I don't think the Intel GPU is immune either.  I suppose one way to check would be to switch completely to software rendering, no hardware acceleration of OpenGl, and see if it passes.

Rik <rik5>
Group administrator
Fri 11 Mar 2016 08:20:56 AM UTC, comment #15: 

On my laptop with Intel graphics:
- Octave-4.0.1-rc3 does not show this bug
- Octave-4.1.0+ (for w64) from Dec. 9 has this bug.)

Maybe it is due a different fltk / osmesa / gl2ps version?

Philip Nienhuis <philipnienhuis>
Group Member
Thu 10 Mar 2016 10:43:59 PM UTC, comment #14: 

I think I hit a hardware-dependent bug here; or maybe it is a problem with osmesa / gl2ps?
With the same mxe 4.1.0+ Octave binary:

- On my desktop PC with NVidia graphics card I can't reproduce this bug.

- On my laptop with integrated Intel graphics this bug shows up consistently.

How do I proceed further ?

I could try with the 4.0.1-rc3 binary on my laptop
I can try with 21333:c4690d9ff566 (virtual functions) backed out
I can try older binaries (I think the oldest 4.1.0+ is from late December; on my desktop I have one from Dec 9 2015)

Philip Nienhuis <philipnienhuis>
Group Member
Wed 09 Mar 2016 09:27:40 PM UTC, comment #13: 

Hold on - it looks like a complete Octave tip does not portray the bug as well. I'll investigate further.

If so, it must be concluded that two separate fresh mxe-octave build environments were wonky; one on my laptop and one on my desktop.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 09 Mar 2016 08:50:12 PM UTC, comment #12: 

Well Rik, it looks like you're off the hook :-)

Backing out 21333:c4690d9ff566 (virtual functions) indeed solves this issue.
John's intuition seems unbeatable.

So, what to do now?

status => In progress

Philip Nienhuis <philipnienhuis>
Group Member
Tue 08 Mar 2016 10:26:33 PM UTC, comment #11: 

Tonight I tried first building / cross-building a tip to try to get rid of bug #47250 comment #14
Unfortunately I had to rebuild mxe-octave itself from scratch on my other build machine => no more time for a try with backed out 21333:c4690d9ff566.  That's for tomorrow night ...

Philip Nienhuis <philipnienhuis>
Group Member
Tue 08 Mar 2016 04:38:04 PM UTC, comment #10: 

@jwe:  I hope you're hunch is better than mine; Otherwise, I'm on the hook to figure WTF went wrong.

Rik <rik5>
Group administrator
Tue 08 Mar 2016 04:28:10 PM UTC, comment #9: 

Hah, my guess is the one about virtual functions.

John W. Eaton <jwe>
Group administrator
Tue 08 Mar 2016 04:24:37 PM UTC, comment #8: 

Combining Philip's and Panxto's observations, it should be a changeset after Feb. 19, 2016 that mentions gl2ps.

I see 4 possibilities:


hlog -k gl2ps -d '> 2/19/2016'
changeset:   21391:13b6be3cb217
user:        Rik <rik@octave.org>
date:        Wed Mar 02 10:09:22 2016 -0800
summary:     Correctly print figure background when multiple axes present (bug #47315).

changeset:   21353:e4fc19d8c6c3
user:        John W. Eaton <jwe@octave.org>
date:        Thu Feb 25 16:15:04 2016 -0500
summary:     remove HAVE_OPENGL from public header file

changeset:   21341:ae384d86196e
user:        Rik <rik@octave.org>
date:        Wed Feb 24 10:48:44 2016 -0800
summary:     Print figure background from OpenGL toolkits (bug #47240).

changeset:   21333:c4690d9ff566
user:        John W. Eaton <jwe@octave.org>
date:        Wed Feb 24 11:08:45 2016 -0500
summary:     avoid warnings about overloading virtual functions from a base class


It will take a long time to go through the MXE build loop, but I would try using bisection and start with 21341.  My hunch is that it will be 21341 or 21391.

Rik <rik5>
Group administrator
Mon 07 Mar 2016 06:53:01 PM UTC, comment #7: 

It must be a changeset from after 19 Feb 2016, as an mxe binary from that date that I had lying around does not have this bug.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 07 Mar 2016 11:01:51 AM UTC, comment #6: 

Thanks.
I'm clueless as regards fltk as well :-)
As usual, I have very little time the coming weeks for unplanned bisecting issues but I may have a look (my curiosity hasn't waned yet).
The point is that as it works fine on Linux, cross-builds using mxe are required and that takes a lot of processing time; "attention time" is less of an issue.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 07 Mar 2016 08:51:25 AM UTC, comment #5: 

I marked this as a regression and switched the category to "plotting with opengl".

As for the actual reason of the failure, I am clueless and don't know fltk code at all. The reason I had forced "fltk" toolkit in the xmlread demo is that it used to be more reliable when it comes to printing ... Any chance you can bisect to find the responsible changeset? If so, you can probably narrow down the search using something like "hg log -k gl2ps -l 25".

Pantxo Diribarne <pantxo>
Group Member
Sun 06 Mar 2016 09:19:41 PM UTC, comment #4: 

The bug applies only to the fltk toolkit; with qt it all seems to work fine.
This is enough:

>> graphics_toolkit fltk
>> plot 1:10
>> print try1.svg


I've retitled the report. Shall I mark it as a regression as well? (I think that seems justified)

Philip Nienhuis <philipnienhuis>
Group Member
Fri 04 Mar 2016 09:38:59 PM UTC, comment #3: 

Do simpler plots, e.g. "plot(1:10)", "patch ()" ..., also trigger the infinite loop?

By the way, even without this bug, the demo doesn't need such a complicated object as a surface to serve its purpose :-).

Pantxo Diribarne <pantxo>
Group Member
Fri 04 Mar 2016 08:36:10 PM UTC, comment #2: 

Right, that sequence triggers the bug. Thanks for helping here.

So this bug must be retitled, do you have a good suggestion?
? infinite loop "GL2PS warning: Unknown token in buffer" when printing plots on Windows ?

Philip Nienhuis <philipnienhuis>
Group Member
Fri 04 Mar 2016 01:22:58 PM UTC, comment #1: 

Hi Phillip,

The example in xmlread is simple and works for me on linux:


close all
graphics_toolkit ("fltk");
hf = figure ();
sombrero ();
print toto.svg


Are you also able to run this example on windows? If not then it may be a windows specific behavior regarding the changes that have been brought to the printing system on default.

Pantxo Diribarne <pantxo>
Group Member
Fri 04 Mar 2016 11:23:33 AM UTC, original submission:  

While trying to generate the html for a new io package release in octave-4.1.0+ in Windows 7, the function generate_package_html (from OF generate-html) gets in an infinite loop (the latter inferred from continuing CPU usage) with:

generate_package_html ("io", "io-html", "octave-forge")
:
< scrolled out of sight / buffer >
< many, many of: >
GL2PS warning: Unknown token in buffer
GL2PS warning: Unknown token in buffer
GL2PS warning: Unknown token in buffer


-messages.
The number of warnings does not increase; I could simply select and copy the gl2ps warnings from the terminal output w/o it scrolling out of sight.
The gl2ps warnings ignored the "more on" setting => that apparently doesn't work on stderr.

In octave-4.0.1-rc1 generate-package-html worked fine, hence "regression" but I didn't enter that tag as it relates to an OF package, not core Octave.

This occurs with OF-generate_html 0.1.9 and 0.1.10.

Perhaps related: during generate_package_html processing a figure was created (probably from an xmlread.m or xmlwrite.m demo), and in octave-4.0.1-rc1 I get warnings:

>> generate_package_html ("io", "io-html", "octave-forge")
[Fatal Error] oct-y7dX18.svg:3213:83: The value of attribute points" associated with an element type "polyline" must not contain the '<' character.
[java] org.xml.sax.SAXParseException; systemId: file:///C:/Users/philip/AppData/Local/Temp/oct-y7dX18.svg; lineNumber: 3213; columnNumber: 83; The value of attribute "points" associated with an element type "polyline" must not contain the '<' character.
warning: delete: __diary__.txt: Permission denied
ans = xmlread: couldn't load and parse "C:\Users\philip\AppData\Local\Temp\oct-y7dX18.svg"
warning: delete: __diary__.txt: Permission denied
str = <?xml version="1.0" encoding="UTF-8"?>
<RootNode created="04-Mar-2016">
    <TextChild useful="no" verbose="yes">These are text data</TextChild>
</RootNode>


Whatever the cause, if  this is related, I think generate_package_html.m shouldn't be hanging due to errors in code it is processing.

Philip Nienhuis <philipnienhuis>
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

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by philipnienhuis (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-10-22 philipnienhuis StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2016-03-09 philipnienhuis StatusNone In Progress
    2016-03-07 pantxo CategoryOctave Package Plotting with OpenGL
        Item GroupIncorrect Result Regression
    2016-03-06 philipnienhuis Summary[OF] generate_package_html.m: infinite loop &quot;GL2PS warning: Unknown token in buffer&quot; [Windows] fltk toolkt: infinite loop "GL2PS warning: Unknown token in buffer" when printing

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code