 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbell net> wrote:
:> : #declare Y = 0;
:> : <X, Y, sin(X/Y)>, 0.1
:>
:> You should always avoid this kind of divisions.
: Can I assume this is because before the count is incremented there is
: a zero value for the division ?
Yeah. You set Y to 0 and then calculate X/Y. This causes division by 0,
of course.
(I don't know if this is what is making povray to crash, but you should
always avoid this kind of problems anyways)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 09 Aug 1999 06:57:50 GMT, Alan Kong wrote:
>On Sun, 08 Aug 1999 17:28:21 -0700, Ken <tyl### [at] pacbellnet> wrote:
>
>>I know you are but what am I ? <Unknown child>
>
> The quote is Paul Reubens (Pee-wee Herman), probably from the movie
>"Pee-wee's Big Adventure". As you may recall, Mr. Reubens was sort of
>blacklisted after an incident in an adult movie house involving no one else
>but himself. He has washed his hands of that whole affair and has been
>working steadily in recent years.
Including a part in the wonderful new movie "Mystery Men." Saw it
this weekend, laughed myself silly. Some of you will tell me I was
already silly; that may be true. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
[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] pacbellnet> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
>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.
>
>camera{location<0,20,20>look_at 0}
>
>light_source{<0,50,100> rgb 1}
>
>#declare Y = 0;
>#while (Y < 50)
> #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
> #declare X = 0;
> #declare Y = Y + 1;
>#end
Howdy!
I've rendered it with POV 3.02 and 3.1g (both for linux).
3.02 rendered it without any errors nor even warnings, but
POV 3.1g generated some division by zero warnings and when
it came to creating vista buffer, segmentation fault
occured (but I didn't gain root ;)
---
Wojtek 'ReaveR' Bauman | admin @127.0.0.1 | rea### [at] spleenwawpl |
http://reaver.spleen.waw.pl | Get PGP: finger bauman@inx.pm.waw.pl
Key ID: 0xCB173E3E | ICQ: 3429749 | *** POV-Ray F O R E V E R ***
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <37afd18c@news.povray.org> , Nieminen Mika <war### [at] cctutfi>
wrote:
> 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.
Yes, I know. As I said, with a different Mac compiler (= different C
libraries) we get problems like that, too. Unfortunately you never know
(without knowing where in the code it happens) if a compiler bug or a code
bug causes writing to an invalid location.
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:
: Yes, I know. As I said, with a different Mac compiler (= different C
: libraries) we get problems like that, too. Unfortunately you never know
: (without knowing where in the code it happens) if a compiler bug or a code
: bug causes writing to an invalid location.
"My code is NOT buggy. The problem must be in the compiler. Or Windows.
Or in intel's cpu. But my code is NOT buggy!" ;)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <37afe9de@news.povray.org> , Nieminen Mika <war### [at] cctutfi>
wrote:
> : Yes, I know. As I said, with a different Mac compiler (= different C
> : libraries) we get problems like that, too. Unfortunately you never know
> : (without knowing where in the code it happens) if a compiler bug or a code
> : bug causes writing to an invalid location.
>
> "My code is NOT buggy. The problem must be in the compiler. Or Windows.
> Or in intel's cpu. But my code is NOT buggy!" ;)
:-) "My computer doesn't work, the screen is always dark. The problem is
the OS, the CPU, Windows, and it is all the programmer's fault. He won't
plug in the power cable for me!"
But serious: Of course we all know that POV-Ray has a lot of small bugs,
like all software of that size has (sad but true). Sometimes it gets worse
because a specific platform/compiler doesn't like a particular bug which is
mostly "harmless" on other platforms.
I.e. on the Mac I recently had to chase a bug that sounds "impossible": When
inserting a CD the POV-Ray core code would abort with an error when parsing
a macro that is in an include file.
Now you say: What does POV-Ray care about CDs? - Nothing, of course! BUT
when mounting the CD the Mac OS would for some reason for a short time
change the global default directory to read from (there is no rule that it
may not). This wouldn't cause any problems using Mac OS file-io (which
doesn't depend on file and path names to find a file "again"). Now, whose
"bug" is it: Is it POV-Ray using standard C io, the Mac OS written in 1983
in Pascal, or the compiler library mapping the standard C io to the Mac file
handling? Everything contributes to it resulting in a bug...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alan Kong wrote:
> The quote is Paul Reubens (Pee-wee Herman), probably from the movie
> "Pee-wee's Big Adventure". As you may recall, Mr. Reubens was sort of
> blacklisted after an incident in an adult movie house involving no one else
> but himself. He has washed his hands of that whole affair and has been
> working steadily in recent years.
I would hope he washed his hands afterwards.
Post a reply to this message
Attachments:
Download 'us-ascii' (1 KB)
|
|
| |
| |
|
|
|
|
| |
|
|
