Bug 687840

Summary: /rangecheck in --fill--
Product: Ghostscript Reporter: Edward <editi>
Component: PDF InterpreterAssignee: Igor Melichev <igor.melichev>
Status: NOTIFIED FIXED    
Severity: normal    
Priority: P3    
Version: master   
Hardware: PC   
OS: Windows 2000   
Customer: Word Size: ---
Attachments: PDF document

Description Edward 2004-12-08 06:39:09 UTC 
When trying to convert the attached PDF file into JPEG with GS Head i get 
a "/rangecheck in --fill--" error. This document converts fine with AFPL GS 
8.14
Comment 1 Edward 2004-12-08 06:39:49 UTC 
Created attachment 1084 [details]
PDF document
Comment 2 Alex Cherepanov 2004-12-08 18:24:07 UTC 
On my box the following command works fine.
    gswin32c -dNOPAUSE -dBATCH -sDEVICE=jpeg -r400 -sOutputFile=834.jpg file.pdf
but -r600 fails with:
    *** C stack overflow. Quiting...
Comment 3 Ray Johnston 2004-12-13 10:38:34 UTC 
This fails with /rangecheck in --fill-- using a build on windows
of 8.50 using MSVC 6 SP3.

The commandline was:

   gswin32c -r72 bug_687840.pdf
Comment 4 Igor Melichev 2004-12-13 11:51:13 UTC 
Can't reproduce with MSVC8. Need to install MSVC6.

Edward, when you convert to jpeg, what resolution do you use ? Please supply a 
sample command line for sure.
Comment 5 Edward 2004-12-13 21:04:27 UTC 
Igor,
i just downloaded the latest GS from cvs (gs v8.51) and tried it again - same 
error.

Here is the command line i have been using
gswin32c -dNOPAUSE -dBATCH -sDEVICE=jpeg -r400 -sOutputFile=out.jpg -f test.pdf

my environment is Win 2003 Server / SP1 + Visual Studio 6 SP5.

PS. are you using the VC++ 2005 express beta or the full VC++ 2005?
Comment 6 Edward 2004-12-13 21:32:03 UTC 
Here is the error i get:

Error: /rangecheck in --fill--
Operand stack:
   --dict:7/7(L)--   0.0   85.0586
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --
nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --
nostringval--   false   1   %stopped_push   1   3   %oparray_pop   1   3   %
oparray_pop   1   3   %oparray_pop   --nostringval--   --nostringval--   2   
1   1   --nostringval--   %for_pos_int_continue   --nostringval--   --
nostringval--   --nostringval--   --nostringval--   %array_continue   --
nostringval--   false   1   %stopped_push   --nostringval--   %
loop_continue   --nostringval--
Dictionary stack:
   --dict:1122/1686(ro)(G)--   --dict:0/20(G)--   --dict:75/200(L)--   --
dict:75/200(L)--   --dict:105/127(ro)(G)--   --dict:247/347(ro)(G)--   --
dict:21/24(L)--   --dict:4/6(L)--   --dict:21/32(L)--   --dict:1/1(ro)(G)--   -
-dict:3/5(L)--
Current allocation mode is local
Comment 7 Edward 2004-12-13 22:05:34 UTC 
Igor,
i just downloaded the MS VC++ 2005 express beta 1 and compiled the GS with it -
 the document converts just fine, so this error is related only to GS compiled 
with MS VC6.
Comment 8 Igor Melichev 2004-12-14 01:13:31 UTC 
I use Microsoft Visual C++ 2005   55603-000-0000016-00520. It is a beta release 
from the MSDN 2004 subscription.

Edward, please in form me whether you run debug or release build. Thank you.
Comment 9 Igor Melichev 2004-12-14 02:50:20 UTC 
I reproduced the 'rangecheck' with MSVC6 release build. Debug build of MSVC6 
doesn't fail. I can't reproduce the stack overflow, which Alex claims. I recall 
that we've got another bug from Alex with stack overflow on his Windows NT, but 
I couldn't find it shortly.
Comment 10 Igor Melichev 2004-12-14 03:36:07 UTC 
Well, I traced it with MSVC6 and inserting some global static variables as 
backups for local data. Observing the static data backups, I conclude that 
gsfunc3.c ln 370 :

         w1 = (min(vv1, b1) - b0) * (e1 - e0) / (b1 - b0) + e0;

is computed inprecisely : the result is -5.15055e-9 while the mathematical 
result is 0. The negative value causes the rangecheck in 
gs_function_is_monotonic. A better precision for this case would be obtained 
with changing the order of * and /, but I'm not sure that it's a best solution.