Thu 05 Sep 2013 11:48:03 PM UTC, comment #13:
Done.
http://hg.savannah.gnu.org/hgweb/octave/rev/50794f5e2323
|
Thu 05 Sep 2013 09:37:31 PM UTC, comment #12:
Everything seems hunky-dory with the latest changeset. Commit it!
|
Thu 05 Sep 2013 06:47:10 PM UTC, comment #11:
Ok. I've added some additional checking on the inputs. New changeset it attached.
(file #29018)
|
Thu 05 Sep 2013 03:26:24 PM UTC, comment #10:
With your new changeset I no longer get any crashes. However, when I use a format that is not a match for "case opts.ghostscript.device" I get a file in the current directory named '-'. I think this was meant to go to stdout, or maybe to lpr, rather than to the file '-'.
Separate issue, when I test the case branch that begins with epslatex I get
Given that this branch needs to create two files, NAME.tex and NAME.eps, we should probably just issue an error if the filename is null because we don't want to send both files to the printer.
|
Thu 05 Sep 2013 12:08:20 PM UTC, comment #9:
Thanks Rik,
I've attached a new changeset with the ghostscript pipe setup in _print_parse_opts_.m
(file #29015)
|
Thu 05 Sep 2013 02:52:20 AM UTC, comment #8:
Ben, I just tried your patch and I still get a segfault on a linux system with gnuplot toolkit.
After some debugging, it appears to be because we call eps_drawnow with a filename of "" from within _gnuplot_drawnow_.m. I added a line to set it in the ".eps" branch of the case statement and it doesn't crash anymore. But, this isn't my area so you should probably take a look at it. (See attached eps.crash.patch) In particular, the code doesn't send anything to the printer, but maybe that is right.
Test code
Note, that it is still possible to get Octave to segfault by using one of the other branches of the case statement such as
This suggests that we should really move the test for a null opts.name above the case statement so it can apply to everyone.
(file #29009)
|
Thu 05 Sep 2013 12:31:20 AM UTC, comment #7:
I've attached a changeset that works for me. I'll run some more tests and push if I don't find any regressions.
I am unable to test a Windows build. Can someone else do that?
(file #29008)
|
Tue 03 Sep 2013 01:29:18 AM UTC, comment #6:
I haven't confirmed, but the problem looks to be that the "-sOutputFile=-" isn't included in the ghostscript options.
http://www.ghostscript.com/doc/current/Use.htm#Pipes
For Unix or Windows the proper pipeline would be,
|
Sat 31 Aug 2013 08:44:26 PM UTC, comment #5:
In the absence of a file name, the print command produces a temporary file which is spooled to the system a printer via lpr. Using the "-debug" will provide information for debugging what goes wrong (the print command works for me on MacOSX)
For Gnuplot ...
For FLTK ...
The diff below will provide more info for debugging.
|
Wed 30 Jan 2013 11:16:37 PM UTC, comment #4:
@Rik:
You're right, this bug only happens with gnuplot (MinGW + MSVC on Windows) - can't test Linux ATM.
@OP:
To invoke fltk: in Octave, type
graphics_toolkit fltk
and try again.
|
Wed 30 Jan 2013 07:42:59 PM UTC, comment #3:
I see this with gnuplot on linux, not sure how use fltk.
|
Wed 30 Jan 2013 04:23:21 PM UTC, comment #2:
Just to help narrow this down, I get this crash only when using gnuplot as the plotting backend. When using FLTK the postscript output is sent to the screen (still not right). Is this behavior also seen by the original bug reporter?
|
Sat 26 Jan 2013 10:24:47 PM UTC, comment #1:
Confirmed in dev version and 3.6.1 on Linux.
Interestingly, this works OK on Windows w. 3.6.1 & 3.6.2 (MinGW & MSVC); that is, all the output meant for the graphical backend is echoed to the Octave terminal (I have no opinion on whether that is expected or Good behavior) but there's no crash.
|
Fri 25 Jan 2013 11:12:58 AM UTC, original submission:
If I do
plot(1); print -deps
Octave crashes with
terminate called after throwing an instance of 'std::out_of_range'
what(): basic_string::substr
panic: Aborted -- stopping myself...
This is -incorrect- use, as a file name should follow the print command.
Nevertheless, a somewhat less dramatic response would be nice.
|