In article <3bee5f5b@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Why is it so difficult to just increase that stack size?

Because it cannot be increased to not crash with a max_trace_level set to
2^31?

>   As for the Windows version: I still don't understand why a bigger stack
> could not be linked to the program. Most compilers have an option to specify
> the stack size the program will use; this stack size is usually very small
> (eg. 8 or 16 kilobytes); just increase it and there you are: You can have
> tens of thousands of recursions in winpov.

The stack size is already at 1024 KB on Windows, and 600 KB on Macs!  Did
you really think POV-Ray would ever run if there was such a low limit as 16
KB?

So how much more should it be to please you?  Ten MB, 100 MB or one GB?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: So how much more should it be to please you?  Ten MB, 100 MB or one GB?

  I'm just not happy with an artificial limit which has been imposed due
to one braindead OS which doesn't even have a dynamic stack for programs.
  I can use almost any max_trace_level in unix, but that will no longer be
true just because another OS can't grasp that.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3bee5f11@news.povray.org...
> Thorsten Froehlich <tho### [at] trfde> wrote:
>   As for the Windows version: I still don't understand why a bigger stack
> could not be linked to the program. Most compilers have an option to specify
> the stack size the program will use; this stack size is usually very small
> (eg. 8 or 16 kilobytes); just increase it and there you are: You can have
> tens of thousands of recursions in winpov.

I agree with Warp here.  I understand that the stack has been set to 1 MB.  I've
done that with just about every non-trivial Windows program I've written.  But
considering what POV-Ray is doing, and if my understanding is correct in that
lots of things get put on the stack, I don't think 4 or even 8 MB would be
unreasonable.  IIRC, in some (most?) compilers you can even set the stack size
at runtime, but that would be a feature request, so consider it just a comment.

Of course, once source is out, we can change it ourselves :-)


>   If you are going to limit the max recursion limit, then at least put
> somewhere an easily modifiable flag that can be switched to get rid of
> this limitation. This way people compiling the unix version can get an
> unlimited version.
>
I completely agree with that.  Also, what limit to use?  Wouldn't some scenes be
able to survive a higher limit than others?

I would say put an extra note about it in the FAQ and leave the rest alone.
Yes, I know people ask stupid questions (I'm guilty on occasion).  but putting
info in two places about it might help head off some of those questions.  I was
actually a little surprised that there is not a section on possible errors, that
is a list of errors with likely causes.  I realize many of the errors are
self-explanatory, but many only make sense if you know what's going on
internally.  Such a list would have helped me several times so far.

By the way, on the topic of stupid questions and why they're asked, I'd like to
explain why I sometimes ask them.  In the case of max_trace_level, I've used it
many times before 3.5.  I've read the manual about before.  But it was a long
time ago, and I didn't figure max_trace_level (which really has only one
purpose) would have changed.  I didn't realize too high a value could cause a
crash.  Until I did it the other day.  And now I see it's in the manual.


Just my 5 cents (I went over the 2 cent limit, I think)

Michael

Post a reply to this message

Redbeard wrote:

> By the way, on the topic of stupid questions and why they're asked, I'd like to
> explain why I sometimes ask them.  In the case of max_trace_level, I've used it
> many times before 3.5.  I've read the manual about before.  But it was a long
> time ago, and I didn't figure max_trace_level (which really has only one
> purpose) would have changed.  I didn't realize too high a value could cause a
> crash.  Until I did it the other day.  And now I see it's in the manual.

The following quote comes straight from the POV-Ray v2.2 docs so it is
obvious that this limitation has been known for many years now -

"Note: Raising max_trace_level will use more memory and time and it could
cause the program to crash with a stack overflow error. Values for
max_trace_level are not restricted, so it can be set to any number as long
as you have the time and memory."


-- 
Ken Tyler

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3beea0b0@news.povray.org...
>   I'm just not happy with an artificial limit which has been imposed due
> to one braindead OS which doesn't even have a dynamic stack for programs.

Frankly, I think you should get your facts right before mouthing off about
supposedly 'braindead' operating systems.

Win32 behaves exactly as it should - it dynamically grows the stack as it's
needed. The default stack size (as given in the EXE) is merely the maximum
stack size, not the initial size.

Put another way, POVWIN has a maximum stack size of 1mb per thread, currently,
as I have to date seen no compelling reason to change this.

-- Chris

Post a reply to this message

On Sun, 11 Nov 2001 00:05:49 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:

>The solution is to change the POV-Ray source code to limit max_trace_level.
>I know some other people will start a flame war now that it is so necessary
>to have an unlimited max_trace_level, but that doesn't change the fact that
>it has to be limited.  Crashing is obviously not an option and a limit is
>the way to fix it.

How about issuing a stack overflow exception or something along the
same line and catching it? This way the program will exit with a
reasonable error message and possibly warn the user about the problem
(or point to the relevant section of the docs :) )


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Chris Cason <newsadmin-despam-@povray-no-spam.org> wrote:
: Win32 behaves exactly as it should - it dynamically grows the stack as it's
: needed.
: The default stack size (as given in the EXE) is merely the maximum
: stack size, not the initial size.

  Ok, then it's better than I thought.
  I had the impression that programs allocate a stack for themselves with just
a regular memory allocation call. Thus the stack will always take the same
amount of memory and its size would be fixed. This would mean that one has to
always find a compromise between stack size and memory usage (ie. it's a waste
of space to reserve a 100MB stack if you are just going to use 1KB of it).

  However, if it's just a maximum size, not a fixed size to be allocated, as
you say, then I don't see any problem in increasing it considerably. If more
memory is not consumed even if a 100MB maximum stack size is specified, then
I don't see any problem in doing this.

: Put another way, POVWIN has a maximum stack size of 1mb per thread, currently,
: as I have to date seen no compelling reason to change this.

  Increasing the possible max_trace_level is a very good reason in my opinion.
People wouldn't have found this limitation (what is it? something like 300?)
if they never would need it.
  Increasing the maximum stack size to 100 times the current should be enough
for everyone. (Yes, pun intended.)
  A max_trace_level limit of about 30000 is very acceptable in my opinion.
Just add to the documentation a visible note that using a bigger
max_trace_level can use lots of memory.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

On 12 Nov 2001 06:56:23 -0500, Warp wrote:
> Chris Cason <newsadmin-despam-@povray-no-spam.org> wrote:
>: Win32 behaves exactly as it should - it dynamically grows the stack as it's
>: needed.
>: The default stack size (as given in the EXE) is merely the maximum
>: stack size, not the initial size.
> 
>   Ok, then it's better than I thought.
>   I had the impression that programs allocate a stack for themselves with just
> a regular memory allocation call. Thus the stack will always take the same
> amount of memory and its size would be fixed. This would mean that one has to
> always find a compromise between stack size and memory usage (ie. it's a waste
> of space to reserve a 100MB stack if you are just going to use 1KB of it).

Nope, a Win32 stack has a "reserve" size and a "commit" size.  The loader 
allocates address space for the "reserve" size, but it only actually maps
memory for the "commit" size.  It then marks the page just below the 
commit as Not Present and waits for it to fault.  When it faults, the OS
maps another page into the address space.  (Theoretically, it's possible 
to blow up an app by decrementing the stack pointer by more than a page.)

This is the reason for the maximum size: it's not a matter of allocated
memory, but of allocated address space.  The stack has to be contiguous.

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Post a reply to this message

Warp wrote:

>   A max_trace_level limit of about 30000 is very acceptable in my opinion.
> Just add to the documentation a visible note that using a bigger
> max_trace_level can use lots of memory.

Out of curiosity, what would you do, render-wise, with a limit of
30 000 ???  (or, if you want, even 300).

Fabien.

Post a reply to this message

In article <slr### [at] fwicom> , Ron Parker 
<ron### [at] povrayorg>  wrote:

> Nope, a Win32 stack has a "reserve" size and a "commit" size.  The loader
> allocates address space for the "reserve" size, but it only actually maps
> memory for the "commit" size.  It then marks the page just below the
> commit as Not Present and waits for it to fault.  When it faults, the OS
> maps another page into the address space

But it cannot shrink the stack this way.  So once you have a stack that is
i.e. 100 MB you have to restart the application.  I think the same problem
exists under Unix.  Unless, of course, you have a system function to shrink
the stack "manually".

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message