 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
[crossposted to .bugreports, note followups]
On Sun, 08 Aug 1999 19:54:58 -0700, Ken wrote:
>
>
>Ron Parker wrote:
>>
>> On Sun, 08 Aug 1999 17:28:21 -0700, Ken <tyl### [at] pacbell net> wrote:
>>
>> >Is this causing a divide by zero error or ? It gets past parsing but
>> >when is gets to building bounding slabs it crashes Pov violently.
>>
>> The crash is not a divide by zero error. I'm not sure what it is, but
>> it might be a stack fault. It crashes somewhere deep within the
>> Visual C++ runtime library for me, in the process of doing a malloc
>> under a pile of calls to sort_and_split. In short, I have no idea
>> what you did here. :)
>
>Do you think it's a bug and maybe someone should report it ? You could
>probably word it in programmerese better than I if you feel it is worth
>bringing to the teams attention.
Yes, it's a bug. Anything that crashes is a bug in my book, whether or
not it's due to bad code. I've copied in the faulty code below, for the
sake of the bug hunters. (The loop on Y wasn't necessary to duplicate
the crash, so I've elided it.)
It may be worth noting that internally POV sets the result of a division by
zero to HUGE_VAL, which is 1e17 by default. It's likely that some code
somewhere in the creation and subdivision of bounding slabs has trouble with
this huge number, which is something like 2^60. I don't understand
sort_and_split all that well, I'm afraid.
------------- cut here -------------
camera{location<0,20,20>look_at 0}
light_source{<0,50,100> rgb 1}
#declare Y = 0;
#declare X = 0;
#while (X < 50)
sphere {
<X, Y, sin(X/Y)>, 0.1
pigment {color rgb<(sin(X/Y) + 1)/2, 0, 0>}
}
#declare X = X + 1;
#end
------------- cut here -------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <37aed849@news.povray.org> , par### [at] fwicom (Ron Parker) wrote:
>>> The crash is not a divide by zero error. I'm not sure what it is, but
>>> it might be a stack fault. It crashes somewhere deep within the
>>> Visual C++ runtime library for me, in the process of doing a malloc
>>> under a pile of calls to sort_and_split. In short, I have no idea
>>> what you did here. :)
>>
>>Do you think it's a bug and maybe someone should report it ? You could
>>probably word it in programmerese better than I if you feel it is worth
>>bringing to the teams attention.
>
> Yes, it's a bug. Anything that crashes is a bug in my book, whether or
> not it's due to bad code. I've copied in the faulty code below, for the
> sake of the bug hunters. (The loop on Y wasn't necessary to duplicate
> the crash, so I've elided it.)
>
> It may be worth noting that internally POV sets the result of a division by
> zero to HUGE_VAL, which is 1e17 by default. It's likely that some code
> somewhere in the creation and subdivision of bounding slabs has trouble with
> this huge number, which is something like 2^60. I don't understand
> sort_and_split all that well, I'm afraid.
I suspect it to be a Windows compiler (or memory allocation library) bug. I
tried the scene up to 450 * 450 spheres without any problems, instabilities
or crashes on my Mac.
With a different Mac compiler we got other bugs like this one (not this
specific one!) deep inside memory allocation code or during complex
operations. Also we did extensive seaching we never found the causes and
maybe the size of POV-Ray just shows lots of the little bugs compilers have
to-date :-(
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
____________________________________________________
Creating bounding slabs.
Scene contains 202500 frame level objects; 0 infinite.
Creating vista buffer.
Creating light buffers.
Displaying...
Rendering...
Done Tracing
untitled.pov Statistics, Resolution 100 x 100
----------------------------------------------------------------------------
Pixels: 10000 Samples: 10000 Smpls/Pxl: 1.00
Rays: 10000 Saved: 0 Max Level: 1/5
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Sphere 332 178 53.61
Bounding Box 3505 333 9.50
Light Buffer 3539 1053 29.75
Vista Buffer 43551 24318 55.84
----------------------------------------------------------------------------
Calls to Noise: 0 Calls to DNoise: 10
----------------------------------------------------------------------------
Shadow Ray Tests: 117 Succeeded: 0
----------------------------------------------------------------------------
Smallest Alloc: 26 bytes Largest: 1620024
Peak memory used: 140421828 bytes
----------------------------------------------------------------------------
Time For Parse: 0 hours 3 minutes 22.0 seconds (202 seconds)
Time For Trace: 0 hours 0 minutes 1.0 seconds (1 seconds)
Total Time: 0 hours 3 minutes 23.0 seconds (203 seconds)
-- [AnimFrame] file#:'untitled.pict' frame#:0 clock:0
Reclaiming memory
-- [Stack] Total Stack space used = 8320 bytes
-- [Finish] File=untitled.pov, Time=09.08.1999 21:29:57 Uhr
----------------------------------------------------------------------------
POV-Ray Mac Memory Cache Statistics
Cache hits: 2513256 Cache misses: 8581
Total calls to malloc: 2521837 Cache hit rate: 99%
---------------------------------------------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In povray.bugreports Thorsten Froehlich <tho### [at] trfde> wrote:
: I suspect it to be a Windows compiler (or memory allocation library) bug. I
: tried the scene up to 450 * 450 spheres without any problems, instabilities
: or crashes on my Mac.
The fact that a program doesn't crash in certain platforms doesn't mean
that the program is bugless.
I once made a program which worked just fine in SunOS and Digital Unix
but crashed in a malloc()-call in Linux. Was there some problem with Linux
memory management?
Not at all! Actually the memory management of Linux was better than the
ones in SunOS or Digital Unix. The bug was in my program (I made an
off-by-one mistake when writing to a table). The memory management of
Linux saw this and crashed the program while SunOS and Digital Unix were
unable to. Thanx to Linux I found the problem and was able to fix it.
So the bug _may_ be in the program although it works in some systems.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
