-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unsafe use of low-level pointer operations #194
Comments
I'll start gathering info for what needs to be fixed. The majority are all in the table handling code. Here is a list of pointer operations in the package:
|
Looking at the unsafe operations in header.jl, we have key = Vector{UInt8}(undef, 81)
# ...
str = unsafe_string(pointer(key)) the same pattern is used 3 times. |
Hello, What I have done in the
I hope this may help to solve the issue in a simple way. |
Many routines in this package derive pointers from managed objects (by calling the
pointer
methods), without explicitly making sure that the objects pointed to are kept alive (usingGC.@preserve
).Example: there's nothing keeping
colnames
alive until the call toffcrtb
FITSIO.jl/src/table.jl
Lines 292 to 330 in 69b9e77
Most of the time, it suffices to make sure to:
However, I also see
ccall
s intolibcfitsio
that leak those pointers to C, so care should be taken that those pointers are not stored over there (if they are, keepingbuf
alive usingGC.@preserve
may not suffice, and you may have to root the object by storing it in an object that's guaranteed to be kept alive for the duration of the pointer being known to the C library).This is very likely the cause for the segfaults seen on PkgEval, as reported in JuliaLang/julia#52951, so for the time being I'll blacklist daily testing of FITSIO.jl and OIFITS.jl. Feel free to ping me or revert the blacklist PR tagged below when the issue is fixed.
The text was updated successfully, but these errors were encountered: