On 19-Jul-08 0:40, alphaQuad wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>> How Camp <hac### [at] gmailcom> wrote:
>>> Heh, in exploring the bounding box crashes I mentioned earlier, I'm now able to
>>> crash POV 3.6 (on winXP) using only a 22-character scene file:
>>> #debug str(1E251,0,-1)
>>   Doesn't crash with the linux version (self-compiled). Might be
>> platform-dependent.
>>
>> --
>>                                                           - Warp
> 
> 
> platform-dependent was my first thought.
> 
> here its
> max factor(170) = 7.257415615307994e+306
> 
> with a ceiling around 1.8e308+INF
yes, a double goes up to 1.7976931348623157e308 but I don't see what 
that has got to do with trying to convert a double of 'only' 1e251 to a 
string. I bet that was the first thing that How checked.

> 
> andrel said:
> pov3.5 does not crash
> 
> 
> TO andrel:
> last time I got vc compiler error on mem damage (tried to free wrong mem)
> I was damaged. I cant see how this is safe for anyone to just test the limits by
> instructing the impossible.
> 
> you can get a good mem checker that will make a boot disc and check mem. thats
> how I confirmed source or errors that followed. Luckily only memory was
> damaged.

I don't think that I got a hardware problem. I just noticed that with a 
slightly smaller number POV crashed with a message that might be more 
useful. The crash seems to be one that happens as secondary damage and 
this error might be closer to the source. So I though it might be 
relevant for people with knowledge of the source but whose POV runs on 
another type of hardware.

Post a reply to this message