bugGNU Octave - Bugs: bug #44806, MXE Octave freezes after print...

 
 

bug #44806: MXE Octave freezes after print command

Submitter:  Avinoam Kalma <avinoam>
Submitted:  Fri 10 Apr 2015 10:30:37 PM UTC
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Avinoam Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Fri 16 Oct 2015 06:38:26 AM UTC, comment #34: 

Many thanks Avinoam for the test.

I am happy to close this one :-).

Pantxo Diribarne <pantxo>
Project Member
Thu 15 Oct 2015 08:47:45 PM UTC, comment #33: 

I have checked it on Windows (MXE-Octave) and it works fine.
Good work!

Avinoam Kalma <avinoam>
Project Member
Sun 11 Oct 2015 07:44:56 PM UTC, comment #32: 

I finally pushed the patch for bug #44765. Looking forward to see what happens on Windows.

Pantxo Diribarne <pantxo>
Project Member
Sun 11 Oct 2015 11:19:33 AM UTC, comment #31: 

Hi,

Could someone with an MXE toolchain and a machine that triggers this bug try the last patch I attached (comment #31 in bug #44765)? Thanks in advance.

Pantxo Diribarne <pantxo>
Project Member
Sat 25 Apr 2015 02:59:09 PM UTC, comment #30: 

Thanks Rik I made bug #44765 depend on this one. I am unsure what the effect is if I close this report as fixed (when confirmed).

Pantxo Diribarne <pantxo>
Project Member
Sat 25 Apr 2015 02:37:39 PM UTC, comment #29: 

Okay.  Back the fix for this bug (#44806) out and re-open bug #44765.  Can you also link #44806, #44463, and #44765 in the bug tracker so we don't accidentally solve one and break the other two.

Rik <rik5>
Project Administrator
Sat 25 Apr 2015 08:08:06 AM UTC, comment #28: 

I just noticed, while looking at timing issues in bug #44463,  that the patch for bug #44765 broke -dpdflatexstandalone output format: the text-less pdf file is broken (nothing is drawn, see below). As this is a regression even on linux, I'd vote for a complete backout as proposed in comment #25 until we find the time to investigate what's actually going wrong in Octave, gl2ps (and)or ghostscript.

graphics_toolkit ("fltk") ## -d*standalone formats don't work with Qt
plot (1:10, ";foo;")
print -depslatexstandalone foo
print -dpdflatexstandalone foo

See attached resulting foo-inc.eps and foo-inc.pdf. The eps seems right but the pdf (AFAIU an eps converted to pdf) is rendered empty (the file is not empty).

(file #33783, file #33784)

Pantxo Diribarne <pantxo>
Project Member
Fri 24 Apr 2015 06:51:00 PM UTC, comment #27: 

Is there a correlation with GPU and or drivers? Nvidia, Intel, ATI?

Anonymous
Fri 24 Apr 2015 05:53:58 PM UTC, comment #26: 

Should we back it out entirely, or should we use #ifdef statements to limit draw_axes() to non-Windows platforms?  It seems a shame to lose something that works for Linux.  But maybe it is only working on Linux because I have an older version of gl2ps.

Rik <rik5>
Project Administrator
Fri 24 Apr 2015 04:51:01 PM UTC, comment #25: 

I'll push the attached cset and reopen bug #44765 if no one has a better idea.

(file #33775)

Pantxo Diribarne <pantxo>
Project Member
Wed 22 Apr 2015 11:49:13 AM UTC, comment #24: 

The OS in bug #44846 was win 7 professional edition 64bit, so indeed pro/family is not the reason for the failure.

Pantxo Diribarne <pantxo>
Project Member
Wed 22 Apr 2015 06:51:45 AM UTC, comment #23: 

I have checked rc3 on 4 Win7 64 bits machines.
On 3 machines rc3 failes to print, on the 4th it OK.
The only difference I can see is that the first 3 are
with Win7 home edition, and the 4th is with win7 professional edition, but I don't think that's the reason for the difference behavior.

Avinoam Kalma <avinoam>
Project Member
Tue 21 Apr 2015 07:45:04 AM UTC, comment #22: 

Thanks Avinoam for thorough testing.
I have posted our issue on gl2ps mailing list [1] and would like  to wait a few days to see if we get an answer before backing-out the change.

Our main clue, for the moment, would be if you could find a common characteristic to the computers that fail: win7 32 or 64 bits, graphics hardware, ...

[1] http://www.geuz.org/pipermail/gl2ps/2015/000408.html

Pantxo Diribarne <pantxo>
Project Member
Tue 21 Apr 2015 05:54:51 AM UTC, comment #21: 

I have checked the "GL2PS warning: Unknown token in buffer".

It is in routine gl2psParseFeedbackBuffer, when the expecrted
 tokens are GL_POINT_TOKEN, GL_LINE_TOKEN,  GL_LINE_RESET_TOKEN, etc... They are defined in GL.h, and their values are 0x000700-0x000706. The new token has value of 1, and that's the reason for
the "Unknown token".

Avinoam Kalma <avinoam>
Project Member
Sun 19 Apr 2015 03:58:12 AM UTC, comment #20: 

I have added checking of return values

+verbatin+
    if (drawn_axes)
      {
        GLint vp[4];
        GLint rv;

        rv = gl2psEndViewport ();
        std::cout << " gl2psEndViewport: " << rv << std::endl;

        glGetIntegerv (GL_VIEWPORT, vp);
        std::cout << "Viewport: " << vp[0] << ", " <<  vp[1] << ", "
                  <<  vp[2] << ", " <<  vp[3] << std::endl;
        rv = gl2psBeginViewport (vp);
        std::cout << " gl2psBeginViewport: " << rv << std::endl;
      }

+verbatim+

>> plot (1:10, ';foo;')


>> print -dpsc e1.ps

### after killing gs.exe
gl2psEndViewport: 0
Viewport: 0, 0, 576, 432
gl2psBeginViewport: 0
GL2PS warning: Unknown token in buffer


but the result is


The return values for gl2psEndViewport and gl2psBeginViewport are both 0.

Avinoam Kalma <avinoam>
Project Member
Sat 18 Apr 2015 06:57:19 PM UTC, comment #19: 

Thanks for testing Avinoam. Unfortunately the viewport is as expected ... I am stuck. Did you try to print error messages as Rik suggested?

We should probably back-out this change before 4.0. In the mean time, I'll make a post on gl2ps mailing list: maybe the warning message together with a description of the way we use gl2psBegin(End)Viewport will ring a bell there.

Pantxo Diribarne <pantxo>
Project Member
Sat 18 Apr 2015 01:40:28 PM UTC, comment #18: 

Adding glFinish did not help.

Again, Octave stops responding until I kill gs.exe, and then I get

Viewport: 0, 0, 576, 432
GL2PS warning: Unknown token in buffer

Avinoam Kalma <avinoam>
Project Member
Fri 17 Apr 2015 09:05:58 PM UTC, comment #17: 

Sorry, should read
"...before "gl2psEndViewport ();" "

Pantxo Diribarne <pantxo>
Project Member
Fri 17 Apr 2015 08:52:11 PM UTC, comment #16: 

There is this comment in gl2ps-renderer.cc, right before gl2psEndPage ():

// Without glFinish () there may primitives be missing in the
// gl2ps output.
glFinish ();

state = gl2psEndPage ();

Maybe adding (in gl2ps-renderer.h) a "glFinish ();" before "gl2psEndViewport (vp);" can sort this out?

Pantxo Diribarne <pantxo>
Project Member
Fri 17 Apr 2015 08:32:55 PM UTC, comment #15: 

@Rik (comment #11):
I did what you asked, using current version with original gl2ps-render.h. I checked the usual example

surf (peaks);
print -dpsc a.ps

and it works. As you said, the problem is in draw_axes of gl2ps-render.h

@Pantxo (comment #16):

I have used your patch. For the previous example it works fine.
For your test "plot (1:10, ';foo;')" Octave freezes forever, or until I kill the gs.exe process. When I kill it,  Octave returns to prompt as you described in comment #9, and I get the output

Viewport: 0, 0, 576, 432
GL2PS warning: Unknown token in buffer

Anything else I could check?

Avinoam Kalma <avinoam>
Project Member
Thu 16 Apr 2015 11:02:19 PM UTC, comment #14: 

@Avinoam: Can you test the attached patch. Note that there must be at least two axes in the figure for the test to be relevant (e.g. "plot (1:10, ';foo;')"). It avoids restarting a new sorting tree while nothing has been drawn in the first one. It also prints the returned values for the GL_VIEWPORT.

(file #33696)

Pantxo Diribarne <pantxo>
Project Member
Thu 16 Apr 2015 10:12:31 PM UTC, comment #13: 

Documentation from gl2ps:

 2.8.2  Description and arguments
gl2psBeginViewport and gl2psEndViewport permit to output different viewports3 in the output stream. Each viewport is sorted separately and has its own background frame. The argument given to gl2psBeginViewport specifies the viewport (obtained for example with a call to glGetIntegerv(GL_VIEWPORT, viewport)).
2.8.3  Return value
gl2psBeginViewport returns:

GL2PS_UNINITIALIZED
    if the library is not initialized;
GL2PS_ERROR
    if an error occurred;
GL2PS_SUCCESS
    otherwise.

gl2psEndViewport returns:

GL2PS_NO_FEEDBACK
    if the feedback buffer is empty;
GL2PS_OVERFLOW
    if the size of the feedback buffer given to gl2psBeginPage is not large enough;
GL2PS_UNINITIALIZED
    if gl2psEndViewport is called when the library is not initialized;
GL2PS_ERROR
    if an error occurred;
GL2PS_SUCCESS
    otherwise.

Another possibility is that we should be doing error checking.  Maybe one of the three gl* functions is returning an error and we should be aborting rather than continuing.

Rik <rik5>
Project Administrator
Thu 16 Apr 2015 10:02:33 PM UTC, comment #12: 

I will check this.

Just a guess:

    gl2psEndViewport ();
    glGetIntegerv(GL_VIEWPORT, vp);

maybe this two lines should be swapped: First, get the viewport,
and then close the view port, and repopen it.

Avinoam Kalma <avinoam>
Project Member
Thu 16 Apr 2015 09:55:53 PM UTC, comment #11: 

@Avinoam: Can you take the current version and copy over only gl-render.cc and check if that works?

I believe it will which then means that it is the small code change to gl2ps-render.h that has the problem

void draw_axes (const axes::properties& props)
{
  // Initialize a new sorting tree in gl2ps, this will make subsequent
  // objects be drawn over previous ones
  GLint vp[4];
  gl2psEndViewport ();
  glGetIntegerv(GL_VIEWPORT, vp);
  gl2psBeginViewport (vp);

  opengl_renderer::draw_axes (props);
}

Rik <rik5>
Project Administrator
Thu 16 Apr 2015 09:44:43 PM UTC, comment #10: 

I can't confirm what you have seen: I have seen the ghostscript
process running, but killing it did not release Octave freeze.

The print command worked in RC-2 but not in RC-3 (versions ftom ftp://alpha.gnu.org/gnu/octave).

To find the bug, I did some lion hunting, a find out that version
http://hg.savannah.gnu.org/hgweb/octave/rev/cbba639b956b worked well, but in version http://hg.savannah.gnu.org/hgweb/octave/rev/438485f6a479 the print command stopped working on my machine.

Moreover, I took current version http://hg.savannah.gnu.org/hgweb/octave/rev/8bfadb26afcd and changed only files libinterp/corefcn/gl-render.cc and libinterp/corefcn/gl2ps-renderer.h to the last working version, and it is still working, so the ball is in your hands now.

Thanks.

Avinoam Kalma <avinoam>
Project Member
Thu 16 Apr 2015 11:48:24 AM UTC, comment #9: 

I had access to the computer used for duplicate bug #44846. I saw that when using fltk, Octave hangs in a call to ghostscript.
When I kill the ghostscript process using the Windows task manager, Octave returns to prompt and obviously the printout is either corrupted or simply missing.
If confirmed, the problem is most probably gl2ps producing an invalid output file and ghostscript hanging while trying to process the file.

@Avinoam: Can you confirm the above behavior? Also, just to be sure, did previous 4.0rc work on the machine on which you see this bug, or is the bug machine dependent whatever the rc binary (not rc dependent)?

Pantxo Diribarne <pantxo>
Project Member
Mon 13 Apr 2015 11:43:50 AM UTC, comment #8: 

Checking on a third Win7 PC, with rc3, I got the same problem.
Any hints, why this happen on one machine, and not on other?

Avinoam Kalma <avinoam>
Project Member
Sun 12 Apr 2015 07:27:51 AM UTC, comment #7: 

Strangely enough, on another Win7 machine, the print command
works well, both for qt and fltk.
I will check on a third machine, to get a winner...

What could be the reason for such behavior?

Avinoam Kalma <avinoam>
Project Member
Sat 11 Apr 2015 03:29:30 PM UTC, comment #6: 

The same problem with

print -depsc a.ps

or

print -deps a.ps

Avinoam Kalma <avinoam>
Project Member
Sat 11 Apr 2015 03:24:45 PM UTC, comment #5: 

Does eps output also hang? If not, this bug could be related to bug #44809 (dead lock when trying to convert to ps?)

Pantxo Diribarne <pantxo>
Project Member
Sat 11 Apr 2015 03:23:07 PM UTC, comment #4: 

The gnuplot toolkit works fine.

for the fltk, I get endless warnings:

GL2PS warning: Unknown token in buffer

before octave stops responding.
The same problem with the plot

graphics_toolkit qt
plot (1:10);
print -dpsc qt.ps

Avinoam Kalma <avinoam>
Project Member
Sat 11 Apr 2015 02:41:50 PM UTC, comment #3: 

Just for the record, can you try with the gnuplot graphics toolktit?  I expect it will work, but that will at least definitively say that it is a problem with the OpenGL toolkits and gl2ps.

graphics_toolkit gnuplot
surf (peaks);
print -dpsc gnuplot.ps

And just in case the problem is with Qt threading

graphics_toolkit fltk
surf (peaks);
print -dpsc fltk.ps

Also, is this only complex plots or is it all plots?

graphics_toolkit qt
plot (1:10);
print -dpsc qt.ps

Rik <rik5>
Project Administrator
Sat 11 Apr 2015 02:33:40 PM UTC, comment #2: 

I have installed rc3 from ftp://alpha.gnu.org/gnu/octave,
and still got the same problem, under Win7

Avinoam Kalma <avinoam>
Project Member
Sat 11 Apr 2015 04:39:00 AM UTC, comment #1: 

Works for me.

Mercurial id: b34a23c8a9c4
MXE id: d135404e71a4

It is awfully slow to print, but it does complete after 5 seconds.

Rik <rik5>
Project Administrator
Fri 10 Apr 2015 10:30:37 PM UTC, original submission:  

Using

surf (peaks)
print -dpsc aa.ps

In octave-4.0.0-rc2 from ftp://alpha.gnu.org/gnu/octave
it works fine. Using http://hg.savannah.gnu.org/hgweb/octave/rev/81c31198a193 from Octave and http://hg.octave.org/mxe-octave/rev/2db17a8585e6 from mxe octave, (using my build) the print command freezes on line 168 of
__opengl_print__.m :

+verbatm+
      drawnow (gl2ps_device{n}, ['|' pipeline{n}]);
=verbatim-

and octave stops responding. Is the problem with my build?

Avinoam Kalma <avinoam>
Project Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33783:  foo-inc.eps added by pantxo (6KiB - image/x-eps)
file #33784:  foo-inc.pdf added by pantxo (3KiB - application/pdf)
file #33775:  backout_44765.patch added by pantxo (1KiB - text/x-diff)
file #33696:  viewport.patch added by pantxo (1KiB - text/x-diff)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (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 project members can vote.

     

     

     

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-10-16 pantxo StatusWorks For Me Fixed
        Open/ClosedOpen Closed
    2015-04-25 pantxo Dependencies- bugs #44765 is dependent
    2015-04-25 pantxo Attached File- Added foo-inc.eps, #33783
        Attached File- Added foo-inc.pdf, #33784
    2015-04-24 pantxo Attached File- Added backout_44765.patch, #33775
    2015-04-16 pantxo Attached File- Added viewport.patch, #33696
    2015-04-11 rik5 CategoryPlotting Plotting with OpenGL
    2015-04-11 rik5 StatusNone Works For Me

    Back to the top


    Powered by Savane 3.9