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

 
 

bug #32319: refresh plot code needed after printing plot

Submitter:  Michael Godfrey <godfrey>
Submitted:  Tue 01 Feb 2011 06:28:29 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:  Michael Godfrey Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 12 Mar 2013 10:22:03 PM UTC, comment #21: 

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

Rik <rik5>
Group administrator
Fri 17 Feb 2012 01:15:36 AM UTC, 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>
Group Member
Thu 29 Sep 2011 04:03:55 PM UTC, comment #19: 

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

Rik <rik5>
Group administrator
Tue 15 Feb 2011 05:54:55 PM UTC, 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>
Sun 13 Feb 2011 05:09:37 AM UTC, 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>
Group Member
Sat 12 Feb 2011 04:39:41 PM UTC, 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
plot(1:200)
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
bug.

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>
Group Member
Sat 12 Feb 2011 09:35:21 AM UTC, 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>
Sat 12 Feb 2011 06:31:30 AM UTC, 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>
Group administrator
Sat 12 Feb 2011 05:13:45 AM UTC, 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

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

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

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>
Group Member
Sat 12 Feb 2011 04:00:52 AM UTC, comment #11: 

Please forget the preceeding comment. I ran test in wrong
system.

More soon.

Michael Godfrey <godfrey>
Group Member
Sat 12 Feb 2011 03:57:37 AM UTC, 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>
Group Member
Sat 12 Feb 2011 01:35:45 AM UTC, comment #9: 

Try this one on top of the previous one.

(file #22654)

Konstantinos Poulios <logari81>
Sat 12 Feb 2011 12:47:39 AM UTC, 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
octave:2>
============================================
Looks like a minor fix is needed.

Michael Godfrey <godfrey>
Group Member
Sat 12 Feb 2011 12:24:25 AM UTC, 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>
Fri 11 Feb 2011 09:54:37 PM UTC, 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>
Fri 04 Feb 2011 07:14:55 AM UTC, comment #5: 

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

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>
Group Member
Thu 03 Feb 2011 07:07:58 AM UTC, comment #4: 

OK, I reopened this report with a new summary.

John W. Eaton <jwe>
Group administrator
Thu 03 Feb 2011 07:03:27 AM UTC, comment #3: 

John,
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 SEG FAULT.

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

Michael Godfrey <godfrey>
Group Member
Thu 03 Feb 2011 06:12:13 AM UTC, comment #2: 

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

http://hg.savannah.gnu.org/hgweb/octave/rev/11427f71699b

John W. Eaton <jwe>
Group administrator
Tue 01 Feb 2011 06:52:59 PM UTC, comment #1: 

The attached, very crude, patch prevents
the SEG FAULT.

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.

Michael


(file #22583)

Michael Godfrey <godfrey>
Group Member
Tue 01 Feb 2011 06:28:29 PM UTC, 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");
    gl2psFree(gl2ps);
    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

Michael Godfrey <godfrey>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #22657:  bug32319-1b.diff added by logari81 (6KiB - text/x-patch)
file #22654:  bug32319-2a.changeset added by logari81 (2KiB - application/octet-stream)
file #22653:  bug32319-1a.changeset added by logari81 (5KiB - 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 (3KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2013-03-12 rik5 StatusNone Fixed
        Open/ClosedOpen Closed
    2011-09-29 rik5 Summaryprinting sometimes fails with error &quot;gl2ps-renderer: fdopen failed&quot; refresh plot code needed after printing plot
    2011-02-12 logari81 Attached File- Added bug32319-1b.diff, #22657
    2011-02-12 logari81 Attached File- Added bug32319-2a.changeset, #22654
    2011-02-12 logari81 Attached File- Added bug32319-1a.changeset, #22653
    2011-02-03 jwe StatusFixed None
        Open/ClosedClosed Open
        SummaryGL2PS error: Bad file pointer printing sometimes fails with error "gl2ps-renderer: fdopen failed"
    2011-02-03 jwe StatusNone Fixed
        Open/ClosedOpen Closed
    2011-02-01 godfrey Attached File- Added gl2ps-renderer.diff, #22583
    2011-02-01 godfrey Attached File- Added fltk_bad_pointer, #22582

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code