bugGNU Octave - Bugs: bug #32319, refresh plot code needed after...


bug #32319: refresh plot code needed after printing plot

Submitted by:  Michael Godfrey <godfrey>
Submitted on:  Tue Feb 1 18:28:29 2011  
Category: Plotting with OpenGLSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Segfault, Bus Error, etc.
Status: FixedAssigned to: None
Originator Name: Michael GodfreyOpen/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich 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)

Tue Mar 12 22:22:03 2013, comment #21:

No follow-ups after a year so presumably the patch did fix things. Closing report

Rik <rik5>
Project Administrator
Fri Feb 17 01:15:36 2012, comment #20:

ping !

With the recent changes to graphics.cc, _init_fltk_.cc, and print.m (below) does this problem persist ?

If so, does adding "waitpid(0)" immediately after the print command resolve the problem?

Ben Abbott <bpabbott>
Project Member
Thu Sep 29 16:03:55 2011, comment #19:

Re-titling bug report to capture the remaining issue to be fixed.

Rik <rik5>
Project Administrator
Tue Feb 15 17:54:55 2011, comment #18:

I have now pushed this changeset. I could also reproduce the issue with the dirty plot window with and without the patch, so we need a seperate bug report for this.

Konstantinos Poulios <logari81>
Project Member
Sun Feb 13 05:09:37 2011, comment #17:

I have done some more tests using slow
connections. The original problem has
not reappeared. So, I am pretty sure that is
is fixed.

However, now that print works reliably there
is an issue: after the print command the
plot window ends up in various states depending
on timing:

1. The display does not change and ends up correct.
2. The display changes during the display (resizes,
for example) and then ends up OK.
3. Ends up all black.
4. There are probaly other states.

Clicking on the plot window usually causes it
to be refreshed to its correct state. But, this
may take a few tries.

So, it would be good to consider some code which is
executed just before exit from the print command
which refreshes the plot window.

In any case, this patch (bug32319-1b.diff) should be
converted to a changeset (add and update to Changelog)
and pushed. It definitely fixes the original problem.
The items above were surely true before, but not
noticed due to Octave crash.

Again, an important problem fixed. Thanks!!!

Michael Godfrey <godfrey>
Project Member
Sat Feb 12 16:39:41 2011, comment #16:

bug32319-1b.diff replaces all previous patches.

This looks good!!!

I will do some more testing, but the test that always failed
now works.

There is a minor point that affects use of fltk generally:
If your WM is configured not to give focus to the plot
window when it is initially created then changes to the window
do not appear until the window is first given focus. After
the first focus things work OK. So, in the case of my print
test, if I just run the test which is simply
print testpdf.pdf
the plot window appears correctly after the plot(1:200)
but ends up as "snow". As soon as I click on it the
correct plot appears. This is just a minor nuisance.

Thanks very much for resolving the long-standing problem.

it the plot appears correctly.

After some more tests I expect to recommend closing this

By the way, the graphics.cc part of the patch got a "patch
offset by 5 lines but succeeded" message with respect to
what I think is the current development tip. You may want
to check this before it is committed.

Michael Godfrey <godfrey>
Project Member
Sat Feb 12 09:35:21 2011, comment #15:

Ok, the misuse of waitpid explains the problem.

However, I have fixed the previous patch witch doesn't use waitpid at all. Could you take a look at?

bug32319-1b.diff replaces all previous patches.

(file #22657)

Konstantinos Poulios <logari81>
Project Member
Sat Feb 12 06:31:30 2011, comment #14:

That is a misuse of waitpid in the _fltk_print_ function. The waitpid function waits for subprocesses given a process ID. But in this context PID is a file ID that refers to a pipe that is open for writing, not a process ID.

John W. Eaton <jwe>
Project Administrator
Sat Feb 12 05:13:45 2011, comment #13:

Again, I was not paying as much attention (doing too many
things at once) as needed. Basically, forget the immediately previous comment.

The make with the 2 patches was OK, and the reported result
shows that it still fails as before.

Sorry about the noise.


Michael Godfrey <godfrey>
Project Member
Sat Feb 12 05:04:47 2011, comment #12:

No, I paniced too soon. The comment was
with respect to the system build with both

But, I should have noticed:

src/graphics.cc:7408: if (++drawnow_executing <= 1)
src/graphics.cc:7456: error ("drawnow: invalid argument, expected `expose' as argument");
src/graphics.cc:7498: error ("drawnow: nonexistent directory `%s'",
src/graphics.cc:7529: error ("drawnow: nothing to draw");
src/graphics.cc:7532: error ("drawnow: invalid debug_file, expected a string value");
src/graphics.cc:7535: error ("drawnow: invalid colormode, expected a boolean value");
src/graphics.cc:7538: error ("drawnow: invalid file, expected a string value");
src/graphics.cc:7541: error ("drawnow: invalid terminal, expected a string value");
src/graphics.df:25: XDEFUN_INTERNAL (drawnow, args, , "-- texinfo --\n@deftypefn {Built-in Function} {} drawnow ()\n@deftypefnx {Built-in Function} {} drawnow (\"expose\")\n@deftypefnx {Built-in Function} {} drawnow (@var{term}, @var{file}, @var{mono}, @var{debug_file})\nUpdate figure windows and their children. The event queue is flushed and\nany callbacks generated are executed. With the optional argument\n@code{\"expose\"}, only graphic objects are updated and no other events or\ncallbacks are processed.\nThe third calling form of @code{drawnow} is for debugging and is\nundocumented.\n@end deftypefn")
This explains why I got the same result as before.

Michael Godfrey <godfrey>
Project Member
Sat Feb 12 04:00:52 2011, comment #11:

Please forget the preceeding comment. I ran test in wrong

More soon.

Michael Godfrey <godfrey>
Project Member
Sat Feb 12 03:57:37 2011, comment #10:

After applying both patches I still get:
octave:2> print testpdf.pdf
error: drawnow: nonexistent directory `/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -dEmbedAllFonts=true -dOptimize=true -dEPSCrop -sPAPERSIZE=letter -dFIXEDMEDIA -sOutputFile=testpdf.pdf /tmp/oct-Kam3Ep.ps - ; rm /tmp/'
error: called from:
error: /d/src/octave/hg/octave/scripts/plot/__fltk_print__.m at line 153, column 5
error: /d/src/octave/hg/octave/scripts/plot/print.m at line 382, column 12
Is part of the problem with the: rm /tmp/

Michael Godfrey <godfrey>
Project Member
Sat Feb 12 01:35:45 2011, comment #9:

Try this one on top of the previous one.

(file #22654)

Konstantinos Poulios <logari81>
Project Member
Sat Feb 12 00:47:39 2011, comment #8:

I tried a test:

octave:1> plot(1:200)
octave:2> print testpdf.pdf
error: drawnow: nonexistent directory `/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -dEmbedAllFonts=true -dOptimize=true -dEPSCrop -sPAPERSIZE=letter -dFIXEDMEDIA -sOutputFile=testpdf.pdf /tmp/oct-KxoDC9.ps - ; rm /tmp/'
error: called from:
error: /usr/local/share/octave/3.5.0+/m/plot/__fltk_print__.m at line 153, column 5
error: /usr/local/share/octave/3.5.0+/m/plot/print.m at line 382, column 12
Looks like a minor fix is needed.

Michael Godfrey <godfrey>
Project Member
Sat Feb 12 00:24:25 2011, comment #7:

Please test the attached patch. Unfortunately I cannot test it right now due to broken graphic drivers but theoretically it should work.

(file #22653)

Konstantinos Poulios <logari81>
Project Member
Fri Feb 11 21:54:37 2011, comment #6:

In _init_fltk_.cc. line 764 drawing is set to printing mode:

canvas->print (fid, term);

then in _init_fltk_.cc. line 768 we call:

mark_modified ();

which triggers graphics redraw that ends up at some canvas->draw asynchronously.

It seems that

waitpid (pid);

at line 159 of _fltk_print_.m is not a sufficient guarantee that the code execution will reach and complete line 160 _init_fltk_.cc:

rend.draw (gh_manager::get_object (number));

where the actual printing takes place before it closes the pipe at line 161 of _fltk_print_.m:

pclose (pid);

Maybe we need some other check.

Konstantinos Poulios <logari81>
Project Member
Fri Feb 4 07:14:55 2011, comment #5:

To provide an aid to fixing this problem,
there are 3 possible results of the print

1. The command completes without showing an
error and the PDF is correct.

2. The error message is displayed and no PDF
is written

3. The command completes without showing an
error, but the PDF is incomplete.

I speculate that the reason for case 3 is that the
gl2ps fdopen executes while the file exists but
has not yet been fully written. This could be
tested by changing the code that writes the file
to lock it until the write is complete.

Michael Godfrey <godfrey>
Project Member
Thu Feb 3 07:07:58 2011, comment #4:

OK, I reopened this report with a new summary.

John W. Eaton <jwe>
Project Administrator
Thu Feb 3 07:03:27 2011, comment #3:

I would not quite call this fixed. The SEG FAULT
is prevented, but the print file does not get
generated. All I accomplished was to prevent

The problem of how to prevent gl2ps from trying
to read the file that has not been written yet remains.

Michael Godfrey <godfrey>
Project Member
Thu Feb 3 06:12:13 2011, comment #2:

Thanks, I checked in this changeset, credited to you:


John W. Eaton <jwe>
Project Administrator
Tue Feb 1 18:52:59 2011, comment #1:

The attached, very crude, patch prevents

The current plot ends up corrupted and
a CR is required before the octave> prompt
appears, but then things look normal and
other plotting can be done.


(file #22583)

Michael Godfrey <godfrey>
Project Member
Tue Feb 1 18:28:29 2011, original submission:

I thought that there was an outstanding report on this, but I
could not find it. In any case, I have tested this problem
and it still happens when fltk plotting is used over a remote
connection or a connection such that graphics rendering takes
too long. This has been a long standing failure. But, I
have an interim suggestion:

The failure now occurs at line 5650 of gl2ps.c:
gl2psMsg(GL2PS_ERROR, "Bad file pointer");
gl2ps = NULL;
return GL2PS_ERROR;
However, the specific cause is at line 46 of gl2ps-renderer.cc:
FILE *fp = fdopen (fid, "wb");
It is the fact that fdopen returns NULL that causes the failure.
Would it be better to test for fp == NULL at this point and if
possible make a non-fatal return? This would be better than the
current SEG FAULT which loses any current work.

I have attached a bt of the current failure. And, I will
try to learn more about the cause of this problem, but I
know little about OpenGL.


Michael Godfrey <godfrey>
Project Member


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

Attach File(s):

Attached Files
file #22657:  bug32319-1b.diff added by logari81 (6kB - text/x-patch)
file #22654:  bug32319-2a.changeset added by logari81 (2kB - application/octet-stream)
file #22653:  bug32319-1a.changeset added by logari81 (5kB - application/octet-stream - patch for testing)
file #22583:  gl2ps-renderer.diff added by godfrey (634B - application/octet-stream)
file #22582:  fltk_bad_pointer added by godfrey (3kB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by bpabbott (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by logari81 (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by godfrey (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 13 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue Mar 12 22:22:03 2013rik5StatusNone=>Fixed
    Thu Sep 29 16:03:55 2011rik5Summaryprinting sometimes fails with error "gl2ps-renderer: fdopen failed"=>refresh plot code needed after printing plot
    Sat Feb 12 09:35:21 2011logari81Attached File-=>Added bug32319-1b.diff, #22657
    Sat Feb 12 01:35:45 2011logari81Attached File-=>Added bug32319-2a.changeset, #22654
    Sat Feb 12 00:24:25 2011logari81Attached File-=>Added bug32319-1a.changeset, #22653
    Thu Feb 3 07:07:58 2011jweStatusFixed=>None
      SummaryGL2PS error: Bad file pointer=>printing sometimes fails with error "gl2ps-renderer: fdopen failed"
    Thu Feb 3 06:12:13 2011jweStatusNone=>Fixed
    Tue Feb 1 18:52:59 2011godfreyAttached File-=>Added gl2ps-renderer.diff, #22583
    Tue Feb 1 18:28:29 2011godfreyAttached File-=>Added fltk_bad_pointer, #22582

    Back to the top

    Powered by Savane 3.1-cleanup1