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

 
 

bug #44806: MXE Octave freezes after print command

Submitted by:  Avinoam Kalma <avinoam>
Submitted on:  Fri 10 Apr 2015 10:30:37 PM UTC  
 
Category: Plotting with OpenGLSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Segfault, Bus Error, etc.
Status: FixedAssigned to: None
Originator Name: AvinoamOpen/Closed: Closed
Release: devOperating 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 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.

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-

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

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 ():

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

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

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:

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:

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

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

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.

And just in case the problem is with Qt threading

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

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

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 File(s):
   
   
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
  • -unavailable- added by pantxo (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by avinoam (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 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 16 Oct 2015 06:38:26 AM UTCpantxoStatusWorks For Me=>Fixed
      Open/ClosedOpen=>Closed
    Sat 25 Apr 2015 02:53:06 PM UTCpantxoDependencies-=>bugs #44765 is dependent
    Sat 25 Apr 2015 08:08:06 AM UTCpantxoAttached File-=>Added foo-inc.eps, #33783
      Attached File-=>Added foo-inc.pdf, #33784
    Fri 24 Apr 2015 04:51:01 PM UTCpantxoAttached File-=>Added backout_44765.patch, #33775
    Thu 16 Apr 2015 11:02:19 PM UTCpantxoAttached File-=>Added viewport.patch, #33696
    Sat 11 Apr 2015 02:41:50 PM UTCrik5CategoryPlotting=>Plotting with OpenGL
    Sat 11 Apr 2015 04:39:00 AM UTCrik5StatusNone=>Works For Me

    Back to the top


    Powered by Savane 3.1-cleanup1