 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> My only concern is that this looks to be a compiler issue rather than a
> POV-Ray source code bug.
No, I'm seeing it on Visual C++ 6.0, and it is not a
compiler issue. It is sensitive to way memory is
recycled by the C runtime library. I havn't been
able to nail it, but Purify is reporting "Access to
Free'd Memory".
The bug is real - I'm chasing it now.
These other reports from different platforms reflect
my observation that even a debug binary behaves
differently to a release binary. There is memory
being used that might happen to be valid, or might
happen to be garbage.
--
Nigel Stewart (nig### [at] nigels com)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The bug is real - I'm chasing it now.
I havn't managed to find a fix, but I'll post here
a more detailed description, which I hope will
be helpful to people more familiar with the POV
parser, and the macro and local functionality
in particular.
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 with VC++ 6.0) but
still acesses dangling pointers. Note
that it is not specific to arrays or
recursion of the same macro.
#version 3.1;
#macro Macro1(A)
#local B = A;
B
#end
#macro Macro2(C)
#local D = C;
D
#end
#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':
case '_':
Echo_ungetc(c);
=> Read_Symbol ();
break;
case '\t':
case '\r':
Parse_RValue [PARSE.C:4908]
int Old_Ok=Ok_To_Declare;
int Terms;
=> EXPECT
CASE4 (TNORMAL_ID_TOKEN, FINISH_ID_TOKEN,
TEXTURE_ID_TOKEN, OBJECT_ID_TOKEN)
CASE4 (COLOUR_MAP_ID_TOKEN, TRANSFORM_ID_TOKEN,
CAMERA_ID_TOKEN, PIGMENT_ID_TOKEN)
CASE4
(SLOPE_MAP_ID_TOKEN,NORMAL_MAP_ID_TOKEN,TEXTURE_MAP_ID_TOKEN,ARRAY_ID_TOKEN)
Parse_Declare [PARSE.C:4880]
Parse_Directive [TOKENIZE.C:2422]
Get_Token [TOKENIZE.C:988]
Parse_RValue [PARSE.C:4908]
Parse_Declare [PARSE.C:4880]
Parse_Directive [TOKENIZE.C:2422]
Get_Token [TOKENIZE.C:988]
Allocation location
malloc [dbgheap.c:129]
pov_malloc [mem.c:323]
Create_Entry [TOKENIZE.C:3006]
{
SYM_ENTRY *New;
=> New = (SYM_ENTRY *)POV_MALLOC(sizeof(SYM_ENTRY),
"symbol table entry");
#if 0
printf("Create_Entry index: %d name: %s number: %d
entry: %d\n",Index,Name,Number,New);
#endif
Add_Symbol [TOKENIZE.C:3070]
{
SYM_ENTRY *New;
=> New = Create_Entry (Index,Name,Number);
Add_Entry(Index,New);
return(New);
Parse_Declare [PARSE.C:4817]
EXPECT
CASE (IDENTIFIER_TOKEN)
=> Temp_Entry = Add_Symbol
(Local_Index,Token.Token_String,IDENTIFIER_TOKEN);
Token.NumberPtr = &(Temp_Entry->Token_Number);
Token.DataPtr = &(Temp_Entry->Data);
Previous = Token.Token_Id;
Parse_Directive [TOKENIZE.C:2422]
}
else
{
=> Parse_Declare ();
Curr_Type = Cond_Stack[CS_Index].Cond_Type;
if (Token.Unget_Token)
{
Get_Token [TOKENIZE.C:988]
Parse_RValue [PARSE.C:4908]
Invoke_Macro [TOKENIZE.C:3258]
Read_Symbol [TOKENIZE.C:1816]
Free location
free [dbgheap.c:955]
pov_free [mem.c:545]
Destroy_Entry [TOKENIZE.C:3049]
Destroy_Ident_Data (Entry->Data,Entry->Token_Number);
=> POV_FREE(Entry);
return(Next);
}
Destroy_Table [TOKENIZE.C:2989]
while (Entry)
{
=> Entry = Destroy_Entry(Entry);
}
Table->Table[i] = NULL;
Return_From_Macro [TOKENIZE.C:3355]
}
/* Always destroy macro locals */
=> Destroy_Table(Table_Index--);
}
void Destroy_Macro(POV_MACRO *PMac)
Parse_Directive [TOKENIZE.C:2095]
Get_Token [TOKENIZE.C:988]
Parse_Num_Factor [express.c:707]
Parse_Num_Term [express.c:875]
Parse_Rel_Factor [express.c:940]
I hope it helps.
I'm off to the beach!
Nigel
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks to everyone that tested the "crash-file".
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 ?
Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
If you guys now are sure it is a bug and that it should
be reported, I will be glad to do so if it makes it go
away any sooner.
But I have never reported a bug before, so therefore
I would appreciate any help to do that.
One concern of mine is that it seems like some of you
know more about the error than me:
Would it be more natural that the one of you that know
most about the nature of the error, posts the report?
I have noticed that several other users have replied
with reports of problems with the file I posted.
Is it necessary to get reports from more users?
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html
Ken wrote:
>
> Chris Colefax wrote:
>
> > As regards fixing the problem in future versions, it might be helpful if
> > others here could test the code on their systems first. This should help to
> > narrow down the problem before you set about posting an official bug-report
> > (after which I might hand over to Ken, who I'm sure can provide details on
> > how this should be done...!).
>
> As far as this being a verifiable bug I will go by Ron Parker's philosophy
> that anything that crashes the program is a bug and should be reported.
> It is clear that a good short example has been provided that can reproducibly
> cause the crash to happen on more than one machine. The next step is to
> hopefully get one of the programmers to step in and offer an explanation
> as to why it is happening. Even if is does not get a comment by one of
> the programmers the offending code and details of the problem should
> be submitted to povray.bugreports on this server. The bug report should
> mention that the bug has be confirmed by a couple of different people
> here in .general. The POV-Team can track down and fix the problem from
> there.
>
> If any help is needed in posting or wording the bug report let me know
> and I'll do what I can to help.
>
> --
> Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor Olav Kristensen wrote:
>
> If you guys now are sure it is a bug and that it should
> be reported, I will be glad to do so if it makes it go
> away any sooner.
It probably will not go away until POV-Ray v3.5 is released
(exact date unknown).
> But I have never reported a bug before, so therefore
> I would appreciate any help to do that.
>
> One concern of mine is that it seems like some of you
> know more about the error than me:
>
> Would it be more natural that the one of you that know
> most about the nature of the error, posts the report?
>
> I have noticed that several other users have replied
> with reports of problems with the file I posted.
> Is it necessary to get reports from more users?
I think there has been enough platform verification and follow-up
information on this that a properly worded bug report can now be
posted.
A properly worded bug report will include the following:
1. You computer system - OS type and version, system ram, processor
2. POV-Ray version and compiler used - i.e. POV-Ray for Windows v3.1g watcom
3. Describe the nature of the problem in as much detail as you can.
4. Provide a sample of code than can be used to reproduce the problem.
5. Provide a list of platforms that the bug has been verified on.
It wouldn't hurt to mention that a POV-Ray TAG member has
verified that this is a bug.
I would also suggest you include Nigel's latest observations
on what is causing the problems including the source he posted.
Include this at the bottom of the bug report.
If you feel comfortable about posting this bug report on your
own feel free to do so. Your bug report will not appear immediately
in povray.bugreports as it is a moderated group and will have to
be approved before being posted there. This may take a day or
to before appearing in that group.
If you are not comfortable posting a bug report let us know
and I or one of the other POV-Ray TAG members will do it for
you.
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 17 Mar 2000 19:59:20 -0800, Ken <tyl### [at] pacbellnet> wrote:
>5. Provide a list of platforms that the bug has been verified on.
> It wouldn't hurt to mention that a POV-Ray TAG member has
> verified that this is a bug.
My brother got MSVC (5 or 6, I'm not sure) from work. There's a
debugger in there but it only shows assembler code for the faulty
operation. If it would help, I will post some output from it.
The code posted crashes the official 3.1g (Watcom) but not MegaPOV 0.4
on my computer, a K6III/450/64MB running Win98 SE.
Peter Popov
pet### [at] usanet
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kens instructions are quite valid, I add my
comments here to clarify what we already know:
> 1. You computer system - OS type and version, system ram, processor
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.
> 2. POV-Ray version and compiler used - i.e. POV-Ray for Windows v3.1g watcom
Seems to apply to all versions of 3.1g.
My impression is that this quite a tricky one to
untangle, and I would urge that someone familiar
with the parser, (tokenise.c and parser.c) or
were involved in the original macro implementation
- be asked to look at this, if at all possible.
I think that this knowledge, plus a good debugger,
plus a tool like Purify, are the basic requirements
for tackling this.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Can this mean that POV-Ray doesn't recognize
> the array as an array if its passed through
> a macro like mine twice ?
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.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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)
Alf
http://www.peake42.freeserve.co.uk/
http://ourworld.compuserve.com/homepages/Alf_Peake/
Tor Olav Kristensen <tor### [at] hotmailcom> wrote in message
news:38D179EE.A2599BC1@hotmail.com...
> The file below makes my copy of POV-Ray stop executing.
>
> And then "Dr. Watson" in Windows NT 4.0 (Build 1381: Service Pack 4)
> claims that there has been a program fault in pwengine.exe
>
> The PC has an AMD K6 200 MHz MMX processor and 128 MB RAM.
>
> I am using plain POV-Ray v3.1g.watcom.win32 (Pentium II optimized)
>
> Can someone else please also try to run the file below and tell me
> about the result?
>
> Regards
>
> Tor Olav
>
> mailto:tor### [at] hotmailcom
> http://www.crosswinds.net/~tok/tokrays.html
>
> file://-----------------------------------------------------
>
> #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))
>
> file://-----------------------------------------------------
>
>
Post a reply to this message
|
|
| |
| |
|
|
From: Tor Olav Kristensen
Subject: Re: POV-file that crashes POV-Ray: Bugreport posted
Date: 24 Mar 2000 10:44:07
Message: <38DB8C20.5F20773B@online.no>
|
|
|
| |
| |
|
|
I have now posted a bug report about the problem.
It's available in the povray.bugreports newsgroup:
"Macros and Arrays in POV-Ray v3.1" 22. March 2000
Tor Olav
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html
Ken wrote:
> I think there has been enough platform verification and follow-up
> information on this that a properly worded bug report can now be
> posted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
