I'm not sure if this is known yet, but I'm working with a scene and I set
max trace level to 512 in global_settings, evertime I run the scene it
crashes, occasionally It gives me an error message other times it just
exits. I tried it with both compiles of beta 7, same thing. I'll post the
scene files in p.b-t.b

thanks

--
Kevin
http://www.geocities.com/qsquared_1999/

Post a reply to this message

In article <3bed84a1$1@news.povray.org> , "Kevin Loney" <klo### [at] pt2mcom> 
wrote:

> I'm not sure if this is known yet, but I'm working with a scene and I set
> max trace level to 512 in global_settings, evertime I run the scene it
> crashes, occasionally It gives me an error message other times it just
> exits. I tried it with both compiles of beta 7, same thing. I'll post the
> scene files in p.b-t.b

Use a lower max_trace_level.  If the crash goes away, no need to post a
scene.

    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 wrote:
> 
> In article <3bed84a1$1@news.povray.org> , "Kevin Loney" <klo### [at] pt2mcom>
> wrote:
> 
> > I'm not sure if this is known yet, but I'm working with a scene and I set
> > max trace level to 512 in global_settings, evertime I run the scene it
> > crashes, occasionally It gives me an error message other times it just
> > exits. I tried it with both compiles of beta 7, same thing. I'll post the
> > scene files in p.b-t.b
> 
> Use a lower max_trace_level.  If the crash goes away, no need to post a
> scene.

Would the crash be related to the use of high max_trace_levels and the
"stack overflow error" mentioned in the docs under max_trace_level ?

-- 
Ken Tyler

Post a reply to this message

In article <3BEDA69A.448E8BED@pacbell.net> , Ken <tyl### [at] pacbellnet>  
wrote:

> Would the crash be related to the use of high max_trace_levels and the
> "stack overflow error" mentioned in the docs under max_trace_level ?

Yes.

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.


    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 wrote:
> 
> In article <3BEDA69A.448E8BED@pacbell.net> , Ken <tyl### [at] pacbellnet>
> wrote:
> 
> > Would the crash be related to the use of high max_trace_levels and the
> > "stack overflow error" mentioned in the docs under max_trace_level ?
> 
> Yes.
> 
> 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.

Since it is already a documented limitation I see no reason for a flame war
to erupt. People will just have to learn to live with it.

-- 
Ken Tyler

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: The solution is to change the POV-Ray source code to limit max_trace_level.

  Why limit the max_trace_level because of *ONE* platform? Why all other
platforms have to suffer because it crashes in one?
  In Unix I can use virtually any max_trace_level and it will not crash.
If I need to use a max_trace_level of 10000, I can use it; it will work just
perfectly. This is because unix programs do not have a limited stack.

  I don't understand why is it so difficult to just tell the compiler to
make a bigger stack.
  When I was making my triangle mesh smoother program, I had a stack problem
as well. As I had a recursive call, it crashed when the recursion was too
deep. I learned that the compiler generated by default a 8 kilobytes stack
to the program, which is laughably small. What I did was just to tell the
compiler to generate a 1 megabyte stack instead (of course in DOS; as said
earlier, this is not a problem in Unix).

: Crashing is obviously not an option and a limit is the way to fix it.

  A rather harsh way of "fixing" a bug.

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

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

>   Why limit the max_trace_level because of *ONE* platform? Why all other
> platforms have to suffer because it crashes in one?

It crashes all platforms for which the beta is available.  Those platforms
together represent more than 99% of all installed systems, thus it will be a
problem for 99% of all potential users and right now a problem for 100% of
users (because no other versions are available).

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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

>   In Unix I can use virtually any max_trace_level and it will not crash.

Well, I hope you can at least assign a stack limit (or general memory) limit
to processes in any system that supports unlimited stack sizes.  If not, you
would have a problem, and thus all Unix versions I know support such a
limit.

Ask yourself the question what happens if this space has been consumed by
the stack?  You get a signal, one that will force you to terminate POV-Ray
(because it cannot cope with the problem in another way).

Now, I see little difference between a forced termination and a crash from
the _user_ perspective.  So, in conclusion for the user it does absolutely
not matter why POV-Ray quits while rendering - the image cannot be
completed.  What reasonable argument is there to tell the user before and
prevent the problem in advance?  The proper way to do this is to set a limit
in advance so the user can be told _in_advance_, without rendering possibly
for days just to find that it will break somewhere after wasting so much
time*.

As for a new design (read: POV-Ray 4.0), one solution could be to use a
stack data structure, not the program stack.

    Thorsten

* Yes, you could argue POV-Ray could run out of memory while rendering, but
as you might know, by far most memory is consumed during parsing and some is
freed after parsing is done.  Thus such a case will be very, very rare!

____________________________________________________
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:
: Well, I hope you can at least assign a stack limit (or general memory) limit
: to processes in any system that supports unlimited stack sizes.  If not, you
: would have a problem, and thus all Unix versions I know support such a
: limit.

: Ask yourself the question what happens if this space has been consumed by
: the stack?  You get a signal, one that will force you to terminate POV-Ray
: (because it cannot cope with the problem in another way).

  Of course there's a limit: Physical memory.
  However, I think that the trace level has to go to millions before you are
getting even close to filling the stack with a regular-sized scene.
  Of course the scene itself could eat up most of the memory thus leaving
less space for the stack, but in this case a povray's internal limit will
not help. The memory could be so filled that even a recursion level of 10
could fill the stack. Of course this is an extremely rare case, but
theoretically possible. What I'm trying to say here is that imposing an
artificial limit to the recursion level does not help at all in unix. If the
memory fills up, it can run out of stack space, regardless of any internal
limit.

  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.

  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.

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

Thorsten Froehlich <tho### [at] trfde> wrote:
: It crashes all platforms for which the beta is available.

  It doesn't crash in this Solaris machine. :)

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

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