property GKZ_VECTOR not created as expected

[kalmarek]

there is a title, but I don't think it's related to GKZ_VECTOR...

for i in 1:100
@info i
let n = 5

    c = polytope.cube(n)
    pts = Matrix{Rational{BigInt}}(c.VERTICES);
   
    for i in n+1:size(pts, 1)
        let sub_pts = pts[1:i, :]
        
            try
                pc = polytope.PointConfiguration(POINTS=sub_pts)
                pc.TRIANGULATION

                gkz = pc.TRIANGULATION.GKZ_VECTOR
            catch ex
                @error "at i = $i exception was thrown:" ex
            end                
        end
    end    
end;
end

non-deterministically (hence the outer loop) shows:

┌ Error: at i = 17 exception was thrown:
│   ex =
│    Exception occured at Polymake side:
│    property GKZ_VECTOR not created as expected at /home/kalmar/.julia/dev/Polymake/deps/usr/share/polymake/perllib/Polymake/Core/BigObject.pm line 1559.
│    
└ @ Main /tmp/placing.jl:18

to my complete chagrin shifting pc = polytope.PointConfiguration(POINTS=sub_pts) out of the try ... catch ... end block "fixes" the issue....

(the issue is even more pronounced for n=6)

[saschatimme]

Maybe something related to pc being freed? Note that the scoping rules for try block are such that pc is not accessible outside the try block.

[benlorenz]

GC.@preserve pc begin
   gkz = pc.TRIANGULATION.GKZ_VECTOR
end

does help here, so I think pc is freed before the gkz computation is done. According to some extra debug statements I added polymake suddenly sees pc.TRIANGULATION as a generic simplicial complex instead of a triangulation subobject, but for this generic object the GKZ vector does not make sense anymore and cannot be created.

Inside polymake $object->type->full_name changes from GeometricSimplicialComplex<Rational> as PointConfiguration<Rational>::TRIANGULATION to GeometricSimplicialComplex<Rational> because the parent object is removed and a subobject alone will not keep its parent alive.

[saschatimme]

But does this maybe point to a general problem with our Julia bindings? Should we add internally a GC.@preserve to every property lookup?

[benlorenz]

In some sense one can produce the change from triangulation to generic object also in the polymake shell but not within one statement, so the error cannot appear there.

Adding a GC.@preserve might not even help as this would only preserve pc during the lookup for TRIANGULATION, and preserve the pc.TRIANGULATION object during the GKZ_VECTOR lookup, but we would need to preserve pc for the second lookup. I don't really see how that could be done ...

[kalmarek]

@benlorenz thanks for looking into this! I'd just document this bug/feature as a design decision. Even in julia access to subfield must be GC.@preserved when the validity of the subfield depends on the lifetime of parent struct. We've seen exactly the same issue in #225 / #293 btw.

[benlorenz]

We should add a note about this in the documentation.