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

Post a reply to this message

On 18-Jul-08 21:36, How Camp 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)
> 
> Aside from thoughts of starting a 'short crash contest', I'm curious if anyone
> can reproduce this, and whether the same behavior is present in 3.7.
> 
> POV only crashes with str(A,L,P) when the precision (P) is set to -1 (platform
> specific), so I suppose it might not crash on other platforms...
> 
> 
confirmed for win2k
1E250 also crashes here, minimum value until now 2E249
1E249 gives attached error.

pov3.5 does not crash
no beta 3.7 version here

Post a reply to this message

Attachments:
Download 'poverror.jpg' (22 KB)

Preview of image 'poverror.jpg'

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

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.

Post a reply to this message

> no beta 3.7 version here
3.6 abrupt exits,
3.7 beta 27 crashes, but catches the failure and dumps
Win XP Pro SP2

Post a reply to this message

Attachments:
Download 'POV-Ray-3.7.0.beta.27.msvc8.win32-48814EFF.dmp.dat' (42 KB)

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

How Camp 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)
> 
> Aside from thoughts of starting a 'short crash contest', I'm curious if anyone
> can reproduce this, and whether the same behavior is present in 3.7.
> 
> POV only crashes with str(A,L,P) when the precision (P) is set to -1 (platform
> specific), so I suppose it might not crash on other platforms...

that's a good one - nice catch. the fault has been fixed. it's been in the
pov source for a very long time.

thanks,

-- Chris

Post a reply to this message

Chris Cason wrote:
> that's a good one - nice catch. the fault has been fixed. it's been in the
> pov source for a very long time.

I love your quick "fixed, thanks" reply to bug reports. With commercial
software, it would be an automated reply like "Thanks for reporting this to
us. The report has been passed on to our developers", and months later,
*maybe*, an upgrade would have the fix on it.

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> that's a good one - nice catch. the fault has been fixed. it's been in the
> pov source for a very long time.

Glad I can (in some tiny way) contribute back to the community.  Many thanks to
you and the rest of the POV team, Chris, for your hard work.

Post a reply to this message

Chris Cason wrote:
> How Camp 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)
>>
>> Aside from thoughts of starting a 'short crash contest', I'm curious if anyone
>> can reproduce this, and whether the same behavior is present in 3.7.
>>
>> POV only crashes with str(A,L,P) when the precision (P) is set to -1 (platform
>> specific), so I suppose it might not crash on other platforms...
> 
> that's a good one - nice catch. the fault has been fixed. it's been in the
> pov source for a very long time.

Will bugs found during 3.7 development, that turn out to be leftover 
bugs from 3.6, be corrected in 3.6 and published?  As long as 3.7 is in 
beta status, that is?

Regards,
John

Post a reply to this message

John VanSickle wrote:
> Will bugs found during 3.7 development, that turn out to be leftover 
> bugs from 3.6, be corrected in 3.6 and published?  As long as 3.7 is in 
> beta status, that is?

as a general rule we do back-port them. as to whether or not we'll release
another 3.6, it will depend on available time.

-- Chris

Post a reply to this message