All Projects

IDProjectCategoryTask TypeReported InPrioritySeveritySummary  ascStatusProgressDue Date
 204 POV-RayOtherCompatibility Issue3.70 RC3Very LowLow -V is not Verbose=off on Unix Closed
100%
Task Description

In vfe/unix/unixoptions.cpp, -V is defined as a synonym for -​-version, overriding its general meaning of Verbose=off.

 207 POV-RayParser/SDLDefinite Bug3.70 RC3Very LowLow Attempted to redefine float identifier as function ide ...Closed
100%
Task Description
#macro A()
    #local f = function { x }
#end

#local f = 1;
A()

This gives:

File 'bug.pov' line 2: Parse Error: Attempted to redefine float identifier as
 function identifier.

The problem is that this makes using functions in library macros difficult. Basically, they must have a globally unique name that’s not used in any of the macros or files that call the macros. #undef doesn’t really help, because it destroys the identifier in the calling scope.

For example, one of the macros in the standard include files names a function “fn”, so this doesn’t work:

#include "transforms.inc"

#local fn = 42; // fnord?
#local fn_pos = vtransform(x, transform { rotate 30*y } );

The reason for this restriction is explained in Parse_RValue in source/backend/parser/parse.cpp:

    // Do NOT allow to redefine functions! [trf]
    //   #declare foo = function(x) { x }
    //   #declare foo = function(x) { foo(x) } // Error!
    // Reason: Code like this would be unreadable but possible. Is it
    // a recursive function or not? - It is not recursive because the
    // foo in the second line refers to the first function, which is
    // not logical. Further, recursion is not supported in POV-Ray 3.5
    // anyway. However, allowing such code now would cause problems
    // implementing recursive functions after POV-Ray 3.5!

In this case the restriction is applied too broadly: it should be safe to redefine anything other than a function to a function and still avoid it looking like recursion. In fact, there’s a restriction in Parse_Declare specifically to prevent redefining functions.

226POV-RayGeometric PrimitivesPossible Bug3.70 RC3Very LowLowNear-coincident surface accuracyTracked on GitHub
0%
Task Description

This is a transparent box very close to a plane.

box {
    -1, 1
    pigment { rgbf <0, 0, 1, 1> }
}

plane {
    #if (version < 3.7)
        y, -1.0000007
    #else
        y, -1.00007
    #end
    pigment { rgb 1 }
    finish { ambient 1 }
}

camera {
    location <1, 2, 3>
    look_at 0
}

The box is placed 100 times closer to the plane for 3.6, but both 3.6 and 3.7 produce exactly the same black artifact (attached).

So apparently 3.7 is less accurate. (And the exact factor 100 feels suspicious.)

 203 POV-RayRadiosityDefinite Bug3.70 RC3Very LowLow Radiosity artifacts at low error_bound Closed
100%
Task Description

A scene of a hollow sphere viewed from the inside:

difference {
    sphere { 0, 100 }
    sphere { 0, 99 }
    pigment { rgb 1 }
    finish { ambient .4 }
}

global_settings {
    radiosity {
        error_bound .1
    }
}

Rendering produces dark splotches at the centers of the pretrace blocks, as shown in the attached image. Blocks rendered earlier have darker splotches. They also differ in shape between renders even with +HR (but not with +WT1).

Turning “always_sample” on, changing “pretrace_end” to 0.01, or increasing “count” past 1000 makes them imperceptibly faint (they can still be seen by increasing image contrast).

This is possibly a bug, as 3.6 doesn’t produce these artifacts regardless of additional settings.

povray.beta-test thread

326POV-RayOtherDefinite Bug3.70 releaseVery LowLowrestricted setting ignored in 3.7Tracked on GitHub
0%
Task Description

Due to a typo in the conf file parser (introduced, I think, in refactoring after 3.6), the restricted setting is ignored, and access checks aren’t performed.

Fixing this reveals some other issues:

  • %INSTALLDIR%/../../etc is incompletely canonicalized to /usr/local/share/../etc, not /usr/local/etc
  • read+write paths are added to the read list only, so writing is impossible

See attached patch.

Relatedly, I think it would be nice to add a new replacement token %CONFDIR% instead of %INSTALLDIR%/../../etc.

Also, there’s a realpath function that could simplify path handling, though I’m not sure if it’s available on all platforms.

 208 POV-RayParser/SDLDefinite Bug3.70 RC3LowHigh Use-after-free when returning local function or spline  ...Closed
100%
Task Description
#macro A()
  #local foo = function { x }
  foo
#end

#local bar = A();

This causes either a segfault, corruption detected by malloc, or “Parse Error: Unknown user defined function”.

After some debugging I think this is what happens.

In source/backend/parser/parse.cpp, Parser::Parse_RValue is called to define the value of bar. Get_Token is called, which invokes A() and which ultimately returns foo as a FUNCT_ID_TOKEN. This token is handled by CASE_VECTOR in Parse_RValue. The relevant clause calls Parse_Unknown_Vector to parse additional tokens (e.g. “foo ( 1 )”). There aren’t any other tokens, but in the process of determining that, #end is reached and Return_From_Macro destroys the symbol table of A, including foo.

So by the time the CASE_VECTOR clause decides that foo is a function identifier that should be copied, the function is destroyed (both the function itself and its number in the symbol table). So here:

    Temp_Data  = (void *) Copy_Identifier((void *)*Token.DataPtr,*Token.NumberPtr);

if *Token.DataPtr (in this case, a function index) was already overwritten, we get “Unknown user defined function”; if it still has the valid function number, it increments the reference count of the function (which has already been freed) back from 0, and we get a double-free later.

A similar problem occurs when foo is a spline.

A tentative patch for the function case is attached.

Showing tasks 1 - 6 of 6 Page 1 of 1

Available keyboard shortcuts

Tasklist

Task Details

Task Editing