stack overflow on 1 comp but not another. 
Author Message
 stack overflow on 1 comp but not another.

I've a postscript file which I generated using c. It views and prints
perfectly on my RedHat7.0; Linux kernel 2.4.2 on a Pentium III computer;
ghostview version 5.6.x. However, when I attempt to ghostview or print the
same postscript file, I get a stack overflow. That system is a Debian
version 1.x, on a Pentium 200. I don't know the version of ghostscript on
that system

My postscript file has a rather large defined function which includes twelve
paths, each about 500 points in length. So, I've got something rather large,
I realize. If I manual cut out the definition and just copy & paste the
defined function's code every time the function is called, it works. That is
impractical. How can I have a large function like this without having to
concern myself with "backward compatibility." (I realize that isn't the
right terminology.)

Thanks in advance,
Marc



Mon, 01 Mar 2004 23:38:29 GMT  
 stack overflow on 1 comp but not another.

Quote:

>My postscript file has a rather large defined function which includes twelve
>paths, each about 500 points in length. So, I've got something rather large,
>I realize. If I manual cut out the definition and just copy & paste the
>defined function's code every time the function is called, it works. That is
>impractical. How can I have a large function like this without having to
>concern myself with "backward compatibility." (I realize that isn't the
>right terminology.)

In a level 1 printer, the operand stack is likely to be limited to 500
elements. For maximum compatibility, do not exceed that limit (500
elements, so 1 2 moveto is three elements).

Procedures are constructed on the operand stack, and occupy at least
the number of elements in the outer level of the procedure, becoming
one element only after } is seen.

If you want to be able to run in older systems you have to accomodate
that. You have to concern yourself with it, by definition.

One trick is this

{ { 450 elements } exec { 450 more elements } exec ... }
----------------------------------------

Visit http://www.*-*-*.com/ ,
PSAlter, psalters, tea, and small {*filter*} animals. And stuff.  



Mon, 01 Mar 2004 23:53:52 GMT  
 stack overflow on 1 comp but not another.

Quote:

>My postscript file has a rather large defined function which includes twelve
>paths, each about 500 points in length. So, I've got something rather large,
>I realize. If I manual cut out the definition and just copy & paste the
>defined function's code every time the function is called, it works. That is
>impractical. How can I have a large function like this without having to
>concern myself with "backward compatibility." (I realize that isn't the
>right terminology.)

By the way, if each point is 3 elements - x y lineto - then the 12
paths will occupy about 140K as a procedure. That is a lot for the
original laserwriters, which probably don't have that much VM to
spare.  You cannot overcome this by rearranging, only by not using a
procedure, instead explicitly coding the path.
----------------------------------------

Visit http://www.*-*-*.com/ ,
PSAlter, psalters, tea, and small {*filter*} animals. And stuff.  


Mon, 01 Mar 2004 23:55:59 GMT  
 stack overflow on 1 comp but not another.
/func { {450 elements} exec {450 elements} exec . . . } def

That's a clever idea. Also, below, you are right about the size. I have /l
{lineto} def to reduce file size, but my ps files are on the order of 100k.

By the way, both computers were using the same printer -- an HP Laser 1100.

Two sub questions

1) If I have a function which calls others, will it all pile up until the
outermost function is finished, then execute? i.e.

/path1 {x elements} def
/path2 {x elements} def
...
/func { path1 path2 path3 ... } def

because, if not, I could do it that way. Likewise, if I do a slight
modification:

/func {path1 exec path2 exec ...} def

I should be alright, so long as the pathi functions are not too large
themselves.

2) I didn't know about the exec function until now. What if I have the
following:
/m moveto def
/l lineto def

/func {

{ 1 2 m 2 3 l 3 4 l 4 5 l } exec
{ 5 6 l 6 7 l 7 8 l 8 9 l stroke } exec

Quote:
} def

will I get one line for the whole thing like I want, or will the exec leave the
first set of instructions stranded without a 'stroke' instruction?

Am I also right thinking that this will not affect any gsave/grestores because
those are on a separate stack?

Based on the answer of #2, I'll modify the code which generates the postscript
files and have it ensure that an exec gets called every <500 elements.

Thanks,
Marc

Quote:


> >My postscript file has a rather large defined function which includes twelve
> >paths, each about 500 points in length. So, I've got something rather large,
> >I realize. If I manual cut out the definition and just copy & paste the
> >defined function's code every time the function is called, it works. That is
> >impractical. How can I have a large function like this without having to
> >concern myself with "backward compatibility." (I realize that isn't the
> >right terminology.)

> By the way, if each point is 3 elements - x y lineto - then the 12
> paths will occupy about 140K as a procedure. That is a lot for the
> original laserwriters, which probably don't have that much VM to
> spare.  You cannot overcome this by rearranging, only by not using a
> procedure, instead explicitly coding the path.
> ----------------------------------------

> Visit http://www.*-*-*.com/ ,
> PSAlter, psalters, tea, and small {*filter*} animals. And stuff.



Tue, 02 Mar 2004 02:39:36 GMT  
 stack overflow on 1 comp but not another.

Quote:

>1) If I have a function which calls others, will it all pile up until the
>outermost function is finished, then execute? i.e.

>/path1 {x elements} def
>/path2 {x elements} def
>...
>/func { path1 path2 path3 ... } def

The stack is used only during parsing, that is, between { and }.
During execution it is used as you would expect, just for (probably) a
few operands.

Quote:

>/func {path1 exec path2 exec ...} def

That won't work if path1 is a procedure as just "path1" will execute
it.

Quote:

>2) I didn't know about the exec function until now. What if I have the
>following:
>/m moveto def
>/l lineto def

I think you mean

/m { moveto } def

It is faster, but does not have a space saving, to use

/m /moveto load def

Quote:

>/func {

>{ 1 2 m 2 3 l 3 4 l 4 5 l } exec
>{ 5 6 l 6 7 l 7 8 l 8 9 l stroke } exec

>} def

>will I get one line for the whole thing like I want, or will the exec leave the
>first set of instructions stranded without a 'stroke' instruction?

Every operator and operand is completely independent: it puts things
on the stack, or takes them off; adds to the path, or strokes it. It
doesn't matter how these relate to procedures.

Bear in mind that there is a limit for path length too in older
interpreters - 1500 is a good one to assume.

Quote:

>Am I also right thinking that this will not affect any gsave/grestores because
>those are on a separate stack?

Indeed.
----------------------------------------

Visit http://www.*-*-*.com/ ,
PSAlter, psalters, tea, and small {*filter*} animals. And stuff.  


Tue, 02 Mar 2004 03:32:14 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Stack overflow (by what units is stack measured)?

2. stack overflow with large PS file

3. jscript stack overflow

4. IE5 Stack Overflow

5. IE & Netscape Stack Overflow Error HELP

6. Another Stack Overflow Question

7. stack overflow

8. Stack Overflow : 'error ASP 0107 : 80004005'

9. Stack overflow error using Ghostview

10. Send Data, Stack Overflow

11. execution stack overflows

12. problems with 'stack overflow'

 

 
Powered by phpBB® Forum Software