Correctness issue, particularly for Julia 1.12 - use after free bug

[mattwigway]

insert!, intersects, and knn all have code that looks something like this:

        result = C.Index_Intersects_id(rtree.index, pointer(minvalues),
            pointer(maxvalues), UInt32(rtree.ndim), items, nresults
        )

The problem is that pointer uses the vector it's passed implicitly, so does not prevent garbage collection of minvalues and maxvalues between when the pointer is created and when the C function is called. (see this and the last example in the first section here.

This has probably been an issue for a long time, but it does seem at first unlikely that GC would happen to run in between allocation and use here - which is probably why it hasn't been noticed before. It seems changes in the garbage collection in Julia 1.12 make it much more likely that this will happen - I discovered it when this test started reliably failing on 1.12, specifically because this line started returning incorrect results because the correct values are not being inserted.

This builds on #36 and #38.

[asinghvi17]

Looks good to me! And it looks like there are tests as well. If no one objects I'll merge this on Friday

[evetion]

LGTM, thanks for testing and making a PR. The rest of the ecosystem has moved away from using pointers indeed, and lets Julia take care of the convert (by defining Base.unsafe_convert to Ptr) which results in Julia tracking the lifetime for us. For Arrays this is already defined:

julia> Base.unsafe_convert(Ptr{eltype(A)}, A)
Ptr{Float64}(0x000000010bb686b0)

For completeness sake, note that an alternative method is to use https://docs.julialang.org/en/v1/base/base/#Base.GC.@preserve.

[mattwigway]

For completeness sake, note that an alternative method is to use https://docs.julialang.org/en/v1/base/base/#Base.GC.@preserve.

Indeed, and this is extremely useful if you need to work around this issue if you can't immediately upgrade your version of libspatialindex, because you can use GC.@preserve externally to the package functions - for instance, this is what I'm currently doing to work around this issue in production

[asinghvi17]

Can #36 and #38 be closed / were all of their changes incorporated in here?

[mattwigway]

Yes, feel free to close them, or I can when I'm back at my computer.

…

On Fri, Dec 5, 2025, 7:45 PM Anshul Singhvi ***@***.***> wrote: *asinghvi17* left a comment (JuliaGeo/LibSpatialIndex.jl#39) <#39 (comment)> Can #36 <#36> and #38 <#38> be closed / were all of their changes incorporated in here? — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEKNLRDIYBRBLBFRQIC6Q34AIRJJAVCNFSM6AAAAACKV3HO7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMJZGA3TMMJSGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>