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

On Mon, 12 Nov 2001 20:48:44 +0100, Thorsten Froehlich wrote:
> 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".

Threads.

Each thread has its own stack allocation.  Kill the render thread and
restart it, and the stack allocation starts over at the "commit" size again.

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message

"Ken" <tyl### [at] pacbellnet> wrote in message
news:3BEF1927.DABD73B5@pacbell.net...
>
>
>
> 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."
>

I'm not denying it hasn't been there for a long time... it's just that this is
the first time I've run into it being a problem.  Like I said, I probably read
it a long time ago.

Michael

Post a reply to this message

Fabien Mosen <fab### [at] skynetbe> wrote:
: Out of curiosity, what would you do, render-wise, with a limit of
: 30 000 ???  (or, if you want, even 300).

  Perhaps not 30000, but 300 and more could be necessary to render lots of
semi-transparent objects (eg. lens flares, "sprites" which form things like
flames, clouds, etc).
  If people would never need a max_trace_level higher than about 300, then
they wouldn't have found this limit.

-- 
#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

>   Perhaps not 30000, but 300 and more could be necessary to render lots of
> semi-transparent objects (eg. lens flares, "sprites" which form things
like
> flames, clouds, etc).

Please write a (reasonable) POV-Ray scene where you can see the difference
between 50 and 80 levels.

(reasonable means : not a serie of 100 transparent planes)

Fabien.

Post a reply to this message

fabien <fab### [at] skynetbe> wrote:
: Please write a (reasonable) POV-Ray scene where you can see the difference
: between 50 and 80 levels.

  There is a visible difference between 50, 100 and 500 recursions in this
scene. Of course I could have came up with a scene where the difference is
more _important_, but I didn't have time for anything fancier.

global_settings { max_trace_level 500 }

camera { location <-1,2.5,-10> look_at y angle 35 }
light_source { <1000,2000,-1500>, 1 }
plane { y,0 pigment { rgb <1,.8,.4> } }

#declare GrassPatch =
  box
  { <-50,0,0><50,2,.1>
    pigment
    { spherical color_map
      { [0 rgbt <0,0,0,1>][.1 rgb y]
      }
      scale <.02, 1.95, .02>
      translate x*.1
      warp { repeat x*.2 }
      warp { turbulence x*.1 }
    }
  }

#declare S = seed(0);
#declare Ind = 0;
#while(Ind < 1000)
  object { GrassPatch translate <-2+4*rand(S),0,-5+Ind> }
  #declare Ind = Ind + 1;
#end


-- 
#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