 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trf de> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
