Add a New Comment (Rich Markup)
( Jump to the original submission )
Sorry. Got this wrong: We postponed defaulting to "-tight" for bug #48689. That bug does not seem to be resolved yet, too. So the conclusion is the same: Should we revert to "-loose" again?
I'm wondering if we should postpone defaulting to "-tight" for another version (or until this is resolved). We did this for the same reason for Octave 5.
While unfortunate, I don't think this particular bug should hold up the Octave release. It is now been ~20 months since the 5.1 release. We really need to get this out.
The original example leads to intermittent hangs (of gs.exe) and ghostscript errors with Octave 6.0.92 on Windows for me. Do we need to take any action before Octave 6 will be released?
Since the default was reverted back to "-loose" for the 5.1 release, this bug no longer affects Octave 5.1, right? Marking as "dev".
@Rik: "axis auto" is OK even though it will at most avoid a crash for us, testers and developers. Unfortunately bug #48689 is a really serious bug:
As a short term fix, would it be acceptable to add "axis auto" in hold.m's BIST demo #6? This seems like a subtle enough problem that it may not be fixed until the first bug fix release for 5.1.
@Rik: Yes the problem is present in default and may have been there for a while: before Octave 5, the default was "-loose" so we did not use epstool and probably just didn't notice the misbehavior. @Dmitri: epstool is ran through a pipe which is fed directly with the original gl2ps-generated EPS output. Then when closing the pipe, fclose only returns when epstool has finished. So I am pretty sure there cannot be a race condition here. Now about the second issue, the bad bbox when using "-loose", can one of you reproduce it? Actually I am only able to trigger it on my most recent system (linux Mint 19.1, whith Ghostscript 9.26 among others). On debian stretch the bbox is OK after +verbtaim+ demo hold 6 axis auto print -loose -depsc toto.eps -verbatim-
Yes. I am testing against stable tip. eb1d4a619260 (stable) tip just now hanged at ii=3. But subsequent run manged to finish all 100 loops. Dmitri. --
Is this a problem for the upcoming 5.1 release as well? The bug is marked against the development version of Octave.
Any possibility of race condition? Like sending eps file that is still being written to epstool? Dmitri.
"demo hold 6" quite reliably causes problems when printing to EPS format (see bug #55529)
for ii=1:100 ii demo hold 6; ## axis auto print toto.eps -depsc ## -loose close all endfor
This leads to either a crash of Octave, a hang with Ghostscript consuming 100% CPU or a simple error due to Ghostscript returning a bad status. This example doesn't crash, hang or error out if I use "axis auto" prior to printing, so that bug #48689 doesn't come into play. Though, the output figure has a wrong bounding box. See attached "bad_bbox.eps". This example works perfectly well when using the "-loose" print option (which used to be the default in 4.4). So it looks like epstool has problems cropping some of our gl2ps generated EPS files.
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
Depends on the following items: None found
Items that depend on this one: None found
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.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 4 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.12