On Mon, Jan 31, 2011 at 1:58 PM, Ken Sharp
<ken.sharp <at> artifex.com> wrote:
Hello Nikola,
At 02:26 31/01/2011 -0800, you wrote:
I'm not sure which list to post this to, so sorry if this is the wrong one.
There is currently no good place to post these kinds of questions, though we are actively investigating other solutions.
I think your problem is not specific to Ghostscript however, so you might care to try posting in the Usenet group 'comp.lang.postscript' where there are a number of knowledgeable PostScript developers.
I'm using GS (actually ps2pdf, which uses ghostscript) to generate a
document of some 3200 pages. 20 pages before the end (although it varies
depending on version of GS), I get the following error:
ERROR: /stackoverflow in {.findcategory}
Operand stack:
--nostringval--
[snip]
Current allocation mode is local
Current file position is 19015430
ESP Ghostscript 815.02: Unrecoverable error, exit code 1
This is a very elderly version of Ghostscript, and one which I believe was never supported by Artifex. The current version is 9.0 and we are about to release 9.01. I would recommend that you upgrade to start with.
Some of the systems this is supposed to work on I can't change. I can upgrade my own system, but I can't say the same for the others. On my own I'm using 8.71 and the crash happens much later with the following message:
Error: /stackoverflow in /findfont
Operand stack:
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1878 1 3 %oparray_pop 1877 1 3 %oparray_pop --nostringval-- 1861 1 3 %oparray_pop 1755 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- 1836 300198 3 %oparray_pop
Dictionary stack:
--dict:1154/1684(ro)(G)-- --dict:0/20(G)-- --dict:192/200(L)--
Current allocation mode is local
Current file position is 112114568
GPL Ghostscript 8.71: Unrecoverable error, exit code 1
Note the file position here is an order of magnitude greater than the one in 815.02 (I only just noticed that, I misread and thought 815.02 crashed later in the document. I re-checked where it crashes, it is about 500 pages in, which is just about the stack size. 8.71 crashes 30 pages before the end, which is 3170 pages in. Has the stack size been changed in this version?)
Each odd page of the document contains an image which was converted from
JPEG. It's the same image every time. This code:
/RawData currentfile
/ASCII85Decode filter def
/Data RawData << >> /DCTDecode filter def
1.000000000 imageScale
imaegScale is not defined anywhere in this code, so presumably you are including it from somewhere else ?
Sorry, I didn't notice this when pasting. imageScale is defined thus:
/NextWidth 0 def
/NextHeight 0 def
/imageScale {
dup NextWidth mul exch NextHeight mul scale
} def
/NextWidth and /NextHeight are changed in another part of the code (they are not always 0).
/DeviceRGB setcolorspace
{ << /ImageType 1
/Width 885
/Height 150
/ImageMatrix [ 885 0 0 -150 0 150 ]
/DataSource Data
/BitsPerComponent 8
/Decode [0 1 0 1 0 1]
>> image
Data closefile
RawData flushfile
} exec
%(here comes the Base64 of the converted image)
is all I ever push onto the execution stack.
Actually, the objects are created on the operand stack, before being transferred to a dictionary (eg def), used (eg setcolorspace) or moved to the execution stack by the 'exec' operator.
[snip]
Can someone point me in the right direction?
Your code is leaving something on the operand stack, presumably after every invocation. IIRC the operand stack has a limit of 500 objects, in which case it can't reasonably be happening on every page. From your description it seems that approsimately every 6 or 7th page is leaving something on the operand stack.
The operand stack was printed when the execution stopped and as you can see from the printout I sent it contained only one element. This is why I ruled out operand stack from being the cause. Are you saying that this is not really what the operand stack looks like at the moment of overflow?
You have only supplied a part of the job you are running, as you state your code above is used for every *odd* page. Presumably something else is generating the even pages.
I assumed the execution stack was the problem, so I posted the only part of the code that did something to the execution stack. If as you say the operand stack got overflown, then I should be able to track down the leak on my own.
Without seeing a complete example its impossible for me to offer any more concrete information however.
It's OK. The complete example is 113MB large, and I wouldn't know how to narrow it down to where the problem is because if I did, I'd probably know how to solve it. ;)
I'm just asking for a general direction in which to turn to look for my problem. Knowing that it's not the execution stack that overflows helps somewhat, and remembering the changes I made to the program that generates this postscript gives me a fairly vague idea of where to look (and this is much better than what I had to go on before your reply came in).
[snip]
Ken
RSS Feed