severity important because it bite me quite a few time as imagemagick maitenair and it will bite a lot ubuntu/debian user now that /tmp is under tmpfs (think also about quota, it bite me also at work) use the following pdf and run gs -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 "-sDEVICE=pam" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r300x300" \ -dUseCIEColor " -sOutputFile=/tmp/magick--V9s1G26-%08d" -f"/tmp/santillana-21.pdf" If it does not work increase resolution to 4800x4800. Disk will be soon full .... Instead of failling with an helful error, ghostscript will fail with a cryptic error: Error: /ioerror in --showpage-- Operand stack: 1 true Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1910 1 3 %oparray_pop 1909 1 3 %oparray_pop 1893 1 3 %oparray_pop --nostringval-- --nostringval-- 31 1 40 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- 1793 0 9 %oparray_pop --nostringval-- -- nostringval-- Dictionary stack: --dict:1168/1684(ro)(G)-- --dict:1/20(G)-- --dict:82/200(L)-- --dict:82/200(L)-- --dict:109/127(ro)(G)-- --dict:291/300(ro)(G)-- --dict:24/31(L)-- --dict:6/8(L)-- --dict:25/40(L)-- Current allocation mode is local Last OS error: 28 GPL Ghostscript 9.05: Unrecoverable error, exit code 1 Now replace with pngalpĥa output: gs" -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 "-sDEVICE=pngalpha" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r300x300" \ "-sOutputFile=/tmp/magick-W9rQ7cym-%08d" -f"/tmp/santillana-21.pdf" Will fail with another so helpful message "libpng error: Write Error" Please improve the disk full message.... You could decrease severity to wishlist if needed.
Notice this bug is under my hat of debian bug triager of ghostscript
ioerror is the correct error for this situation, according to the Postscript specification, so this is *not* a bug. Changed to enhancement for wider consideration. My recommendation is to just close.
(In reply to comment #2) > ioerror is the correct error for this situation, according to the Postscript > specification, so this is *not* a bug. > > Changed to enhancement for wider consideration. My recommendation is to just > close. ioerror is correct according to spec but some realdevice from HP do it better. For instance they (In reply to comment #2) > ioerror is the correct error for this situation, according to the Postscript > specification, so this is *not* a bug. > > Changed to enhancement for wider consideration. My recommendation is to just > close. Yes it is correct according to the spec. But some HP device (real) in this situation print of my sheet disk full in this case with the ioerror (and it is more helful, i know i need to purge some file on the disk). It is not a bug but a quality of implementation. Change for instance lastos error with the value of strerror will be really helful.
(In reply to comment #3) > > It is not a bug but a quality of implementation. Primary definition of "quality of implementation" is accurately reflecting the specification being implemented. We are accurately reflecting specification.....
(In reply to comment #4) > (In reply to comment #3) > > > > It is not a bug but a quality of implementation. > > Primary definition of "quality of implementation" is accurately reflecting the > specification being implemented. > > We are accurately reflecting specification..... Yes, but notice that I triagge about 4 to 5 bugs per month about this. Our user believe imagemagick or some other high level software that use gs are at fault. After checking it is only a disk ful. Sometimes, they report to ghostscript and I must close as invalid. According to posix a lot of function return implementation defined result when EFAULT, but is a custom to return something that does not hurt.... Note that moreover oserror code name is architecture dependant, and we must check that arch is running, and in the near future the multiarch (aka 32 bits i386 under amd64). Add strerror(errno) instead of a bare errno will be easier for us but also for you because it will need less work to decode the error. Bastien
(In reply to comment #5) > Yes, but notice that I triagge about 4 to 5 bugs per month about this. Our user > believe imagemagick or some other high level software that use gs are at fault. > > After checking it is only a disk ful. If you don't like the Ghostscript error handling its perfectly possible to replace it with your own error handler, the PLRM has details on this. This is also a reason why we *MUST* conform to the specification, custom error handlers have a right to expect us to do so. Now by the time we reach the PostScript interpreter there is no way to know that an 'ioerror' is caused by the disk being full (as opposed to a permissions problem for example). So realistically we cannot give a 'meaningful' error specifically in the case of disk full. Note that for anyone skilled in PostScript ioerror *is* a meaningful error.
PostScript error can have "additional information" associated with the error. Ghostscript provides this string for a handful of errors but can do much more.
(In reply to comment #6) > (In reply to comment #5) > > > Yes, but notice that I triagge about 4 to 5 bugs per month about this. Our user > > believe imagemagick or some other high level software that use gs are at fault. > > > > After checking it is only a disk ful. > > If you don't like the Ghostscript error handling its perfectly possible to > replace it with your own error handler, the PLRM has details on this. This is > also a reason why we *MUST* conform to the specification, custom error handlers > have a right to expect us to do so. > > Now by the time we reach the PostScript interpreter there is no way to know > that an 'ioerror' is caused by the disk being full (as opposed to a permissions > problem for example). So realistically we cannot give a 'meaningful' error > specifically in the case of disk full. > > Note that for anyone skilled in PostScript ioerror *is* a meaningful error. Yes perhaps like 28 == ENOSPC on a lot of linux arch. But it will be better to get instead of 28 "disk full (28)" And it is allowed by the standard according to my reading ( Now if you want the standard PLRM ed3 p 116 'As part of error recovery, the job server executes the name handleerror from errordict. The default handleerror procedure accesses the error information in the $error dictionary and reports the error in an installation-dependent fashion' In some environments, handleerror simply writes a text message to the standard output file. In other environments, it invokes more elaborate error reporting mechanisms.' So only replacing Last OS error: 28 that is I believe printf("Last OS error: %i",errno) by OS error: disk full (28) that is a call to strerror_r() will be sufficient for us bastien
(In reply to comment #8) > And it is allowed by the standard according to my reading ( > Now if you want the standard PLRM ed3 p 116 > 'As part of error recovery, the job server executes the name handleerror from > errordict. The default handleerror procedure accesses the error information in > the $error dictionary and reports the error in an installation-dependent > fashion' And indeed this is what I meant, if you want to replace the Ghostscript error handler, then the capability is there. > So only replacing Last OS error: 28 that is I believe printf("Last OS error: > %i",errno) by OS error: disk full (28) that is a call to strerror_r() will be > sufficient for us strerror_r is a non-standard Linux extension. We could use strerror, it does seem to be supported on Windows (at least in recent versions of MSVC) but I'm by no means certain this is completely portable. We'd need to think what to do if its not available. If Alex wants to implement more error handling then that's up to him, but we shouldn't be using OS-specific code in my opinion.
(In reply to comment #9) > strerror_r is a non-standard Linux extension. Actually its POSIX 1-2001, but we don't require that, so its still not something we want to use. strerror is C89.
(In reply to comment #10) > (In reply to comment #9) > > > strerror_r is a non-standard Linux extension. > > Actually its POSIX 1-2001, but we don't require that, so its still not > something we want to use. strerror is C89. If you are not multithread you could use strerror. Or you could use the gnulib module http://www.gnu.org/software/gnulib/manual/html_node/strerror_005fr.html that is under lgpl2+ and portable. Bastien
(In reply to comment #9) > (In reply to comment #8) > > > And it is allowed by the standard according to my reading ( > > Now if you want the standard PLRM ed3 p 116 > > 'As part of error recovery, the job server executes the name handleerror from > > errordict. The default handleerror procedure accesses the error information in > > the $error dictionary and reports the error in an installation-dependent > > fashion' > > And indeed this is what I meant, if you want to replace the Ghostscript error > handler, then the capability is there. > > > > So only replacing Last OS error: 28 that is I believe printf("Last OS error: > > %i",errno) by OS error: disk full (28) that is a call to strerror_r() will be > > sufficient for us > > strerror_r is a non-standard Linux extension. We could use strerror, it does > seem to be supported on Windows (at least in recent versions of MSVC) but I'm > by no means certain this is completely portable. We'd need to think what to do > if its not available. If strerror is not available let print only error code. Strerror is quite portable see http://www.gnu.org/software/gnulib/manual/html_node/strerror.html#strerror > If Alex wants to implement more error handling then that's up to him, but we > shouldn't be using OS-specific code in my opinion.
(In reply to comment #11) > > Actually its POSIX 1-2001, but we don't require that, so its still not > > something we want to use. strerror is C89. > > If you are not multithread you could use strerror. GS does use threads but only while rendering, I'm uncertain whether this would be likely to cause a problem as this is not my field. > Or you could use the gnulib module > http://www.gnu.org/software/gnulib/manual/html_node/strerror_005fr.html that is > under lgpl2+ and portable. I *really* don't think we want to add another third party library.
(In reply to comment #12) > > strerror_r is a non-standard Linux extension. We could use strerror, it does > > seem to be supported on Windows (at least in recent versions of MSVC) but I'm > > by no means certain this is completely portable. We'd need to think what to do > > if its not available. > > If strerror is not available let print only error code. Yes, but my point was really that we will need (yet another) build flag to optionally switch the behaviour. > Strerror is quite portable see > http://www.gnu.org/software/gnulib/manual/html_node/strerror.html#strerror Its portability doesn't, unfortunately, have much bearing on whether it is available on a given OS/C library. We do have to consider builds on embedded operating systems, many of which are old, and often have poorly supported toolchains. In any event I do not think this needs any further discussion, its up to Alex what he chooses to do about it.
(In reply to comment #14) > (In reply to comment #12) > > > > strerror_r is a non-standard Linux extension. We could use strerror, it does > > > seem to be supported on Windows (at least in recent versions of MSVC) but I'm > > > by no means certain this is completely portable. We'd need to think what to do > > > if its not available. > > > > If strerror is not available let print only error code. > > Yes, but my point was really that we will need (yet another) build flag to > optionally switch the behaviour. > > > > Strerror is quite portable see > > http://www.gnu.org/software/gnulib/manual/html_node/strerror.html#strerror > > Its portability doesn't, unfortunately, have much bearing on whether it is > available on a given OS/C library. We do have to consider builds on embedded > operating systems, many of which are old, and often have poorly supported > toolchains. > > In any event I do not think this needs any further discussion, its up to Alex > what he chooses to do about it. You use autoconf it is only matter of #ifdef HAVE_STRERROR and you have already the mechanism in place. .oserrorstring is defined in zmisc.c but I do not understand enouth gs_init to understand why it is not printed...
(In reply to comment #15) > You use autoconf it is only matter of #ifdef HAVE_STRERROR and you have already > the mechanism in place. We don't use autoconf an all platforms, because it isn't available for all platforms. Yes we can use this on Linux but we still have to be concerned with other platforms. > .oserrorstring is defined in zmisc.c but I do not understand enouth gs_init to > understand why it is not printed... Because the operator .oserrostring is returning 'false' on the stack, which means that gp_strerror() returned NULL or a 0 length string. This would appear to be because the definition of gp_strerror in gp_unix.c is: /* Get the string corresponding to an OS error number. */ /* Unix systems support this so inconsistently that we don't attempt */ /* to figure out whether it's available. */ const char * gp_strerror(int errnum) { return NULL; } I notice that the *Windows* version is: /* Get the string corresponding to an OS error number. */ /* This is compiler-, not OS-, specific, but it is ANSI-standard and */ /* all MS-DOS and MS Windows compilers support it. */ const char * gp_strerror(int errnum) { return strerror(errnum); } I can only assume that at some time in the past there has been an instance of 'Unix' that didn't support strerror. Not up to me whether this is still reasonable, but it seems that only Windows and MSDOS are currently supporting this in GS. I did check the VMS and Mac code and they also do not return error strings.
Created attachment 8786 [details] Patch to support strerror Patch for ghostscript use strerror
Patch applied - thanks for saving me the effort! http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=7dfac701