|
 |
========================================================
Bug report: Macros and Arrays in POV-Ray v3.1
By Tor Olav Kristensen
mailto:tor### [at] hotmail com
http://www.crosswinds.net/~tok/tokrays.html
========================================================
Note:
The problems described below has been "confirmed" by
several different people in the discussion group;
povray.general.
A POV-Ray TAG member has also verified that this is
a bug.
========================================================
My computer system:
PC with an AMD K6 200 MHz MMX processor and 128 MB
system RAM.
Its running Windows NT 4.0
(Build 1381: Service Pack 4, Norwegian)
========================================================
POV-Ray version:
The official POV-Ray for Windows v3.1g watcom release.
(With no patches)
========================================================
The nature of the problem:
Im trying to make nested calls to macros that each is
passed an array as argument and that also returns an
array (see my sample code below):
When I load the sample file enclosed below into the
CodeMax editor and run it, POV-Ray says:
Parsing...
Then POV-Ray stops executing and an error message is
presented (in a window) by "Dr. Watson for Windows NT"
(a diagnosis program that is installed by/with
Windows NT).
Its says (translated from norwegian):
There has been a program fault, and a log for the
program fault has been established (made?).
pvengine.exe
Exception:
Access violation (0xc0000005), Address: 0x004482da
Then after a few seconds POV-Ray disappears from the
screen and from the Windows NT task list.
========================================================
Here is the sample code that was used to reproduce the
problem:
//-----------------------------------------------------
#version 3.1;
#macro TestMacro(MM)
#local QQ = array[3]
#local QQ = MM
QQ
#end
#declare NN = array[3] { 1, 2, 3 }
#declare TestArray = array[3]
#declare TestArray = TestMacro(TestMacro(NN))
//-----------------------------------------------------
========================================================
I'm not sure if this is of any help, but if I rewrite
the code so that it looks like this;
//-----------------------------------------------------
#version 3.1;
#macro TestMacro(MM)
#local QQ = array[3]
#local QQ = MM
array[3] { QQ[0], QQ[1], QQ[2] }
#end
#declare NN = array[3] { 1, 2, 3 }
#declare TestArray = array[3]
#declare TestArray = TestMacro(TestMacro(NN))
//-----------------------------------------------------
then the only error message I get from POV-Ray is that
there is no objects in the scene.
========================================================
The following quotes from the povray.general discussion
group (Thread: "POV-file that crashes POV-Ray" started
17. March 2000 by me) shows which systems the bug has
been (more or less) verified on.
At the end of this email there are also some
statements from Nigel Stewart about the bug, together
with a listing from a debug session that he did.
========================================================
From Chris Colefax (cco### [at] geocitiescom):
The code you posted does not cause problems on my DOS
versions of POV-Ray 3.1a or 3.1e.
However, the file does crash on my copy of 3.1d.
Changing the #local directives within the macro to
global #declare's seems to fix the problem.
....I compiled my copies of 3.1a and 3.1e for myself
(using DJGPP)...
========================================================
From Ken Tyler (tyl### [at] pacbellnet):
It crashes here on POV-Ray for Windows v3.1g watcom
running on my Win98 platform.
========================================================
From Peter Popov (pet### [at] usanet):
The code posted crashes the official 3.1g (Watcom) but
not MegaPOV 0.4 on my computer, a K6III/450/64MB
running Win98 SE.
========================================================
From Nieminen Juha (war### [at] sarakerttunencstutfi):
It doesn't crash my Solaris compile of povray.
It just says:
test.pov:8: error: No objects in scene.
========================================================
(Referring to Nieminen Juhas posting)
From Marc Schimmler (sch### [at] icauni-stuttgartde):
Same is true for my IRIX 6.3 compile.
========================================================
(Referring to Nieminen Juhas posting)
From Serge LAROCQUE (sgl### [at] hotmailcom):
Same here, no crash, but different error message, on
Slackware Linux 4.0:
#local QQ = MM <---- ERROR
crash.pov: 6: error: Attempted to redefine array
identifier as object identifier
========================================================
From Ingo (ing### [at] homenl):
Crash with watcom version 3.1g win.
No crash with 3.1g msvc win and megapov, but error:
out of memory.
Cannot allocate -2116968036 bytes for array.
========================================================
From Alf Peake (alf### [at] peake42freeservecouk):
Povray official reports:
>[snip]
>Writing CW.ERR file....
>
>CauseWay error 09 : Unrecoverable
exception. Program terminated.
>C:\DOS\povray\play>
I'm using Version 3.1g.msdos.wat-cwa, Celery 500, 128M
ram and at this time from w98SE's full screen dos.
Can upload CW.ERR if asked.
Povray unofficial - no problems. This is on same box
and setup as above but using:
>Persistence of Vision(tm) Ray Tracer v3.1g.dmp.0.4 (DosMegaPov
0.4).msdos.gcc
>This is an unofficial version (DosMegaPov) compiled by:
>Stuart Gibson (email: sgi### [at] sgibcouk)
========================================================
From Tor Olav Kristensen (tor### [at] hotmailcom):
I have myself also tested it on a dual 300 MHz Pentium
processor PC running Red Hat Linux.
The POV-Ray version was an unofficial version:
3.1g.Linux.gcc compiled by Red Hat Software.
The error message went something like this:
#local QQ = array[3]
#local QQ = MM <----ERROR
error: Attempted to redefine array identifier as object
identifier.
Can this mean that POV-Ray doesn't recognize the array
as an array if its passed through a macro like mine
twice ?
========================================================
(Referring to my question above)
From Nigel Stewart (nig### [at] nigelscom):
POV is being confused by garbage data, or to be more
exact: a dangling pointer.
I was able to produce more than two different error
messages, on Windows NT, for the same POV scene.
========================================================
From Nigel Stewart (nig### [at] nigelscom):
We know that this is not system specific, but impacts
different systems differently. In some circumstances,
nothin obviously goes wrong - but the underlying flaw
is still evident.
========================================================
From Nigel Stewart (nig### [at] nigelscom):
The problem seems to be that a macro that emits data on
the basis of a local, can leave a dangling pointer.
Sometimes this pointer is still pointing at the right
value, sometimes it is pointing at garbage - it depends
on the C runtime library being used for memory management.
Here is a simpler POV scene that does not crash POV
(Windows binary, or my compiled command line binaries
#local Z = Macro1(Macro2(1.0));
When the parser attempts to get the data associated with
"A" when emitting Macro1, Purify catches a "freed memory
access".
It seems that the data was freed when Macro2 completes
processing and the symbol table for it is destroyed.
Here is the full detail of the purify report:
[E] FMR: Free memory read in Read_Symbol {1 occurrence}
Reading 4 bytes from 0x023307fc (4 bytes at 0x023307fc illegal)
Address 0x023307fc is 36 bytes into a 40 byte block at 0x023307d8
Address 0x023307fc points to a malloc'd block in heap 0x022f0000
Thread ID: 0xc1
Error location
Read_Symbol [TOKENIZE.C:1880]
else
{
Par = (POV_PARAM
*)(Temp_Entry->Data);
=> Token.Token_Id = *(Par->NumberPtr);
Token.NumberPtr = Par->NumberPtr;
Token.DataPtr = Par->DataPtr;
}
Get_Token [TOKENIZE.C:1171]
case 'Z':
========================================================
Post a reply to this message
|
|
