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
|
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?
|
Thu 29 Sep 2011 04:03:55 PM UTC, comment #19:
Re-titling bug report to capture the remaining issue to be fixed.
|
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.
|
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!!!
|
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.
|
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)
|
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.
|
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
|
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.
|
Sat 12 Feb 2011 04:00:52 AM UTC, comment #11:
Please forget the preceeding comment. I ran test in wrong
system.
More soon.
|
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/
|
Sat 12 Feb 2011 01:35:45 AM UTC, comment #9:
Try this one on top of the previous one.
(file #22654)
|
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.
|
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)
|
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.
|
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.
|
Thu 03 Feb 2011 07:07:58 AM UTC, comment #4:
OK, I reopened this report with a new summary.
|
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.
|
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
|
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)
|
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
|