Usage of global scope by Linker is unsafe for pointers to `static` data in loaded library

[Maurizio Cimadamore]

Some additional notes, as we dug into this more.

The main issue you describe is this:

            What makes this worse is that if you are just given a
            SymbolLookup, or even a MemorySegment obtained from it, you
            don’t
            have access to the original Arena used to load the library, so
            you cannot even manually fix this unsafety this by using
            |MemorySegment#reinterpet| to change the Arena.

            A similar problem to the one you cite was mentioned in this
            document we shared a while ago:

https://cr.openjdk.org/~mcimadamore/panama/scoped_arenas.html

See section on “co-allocation”.

At the time we concluded (based on feedback) that the usefulness of the 
proposed factory to “convert” a scope back into an Arena was limited. As 
such we decided to leave that out. That is, even if we could see that 
there were cases where a client might expect to e.g. be able to allocate 
a new segment with the same lifetime of an existing segment, the cases 
where this came up seemed rather obscure, and even then, it wasn’t clear 
as to whether it was something that was 100% ok for the client to be 
wanting to do.

You seem to have use case where you need to perform a reinterpret - but 
have no Arena. Can you please share more about your use case? E.g. are 
you really in a situation where you don’t have an Arena, or are you 
concerned about a case where you /might/ not have one?

For instance, in the case you mention there is a native library. This is 
loaded using a SymbolLookup - probably SymbolLookup::libraryLookup. This 
lookup takes an Arena. If you are using jextract, jextract will emit a 
constant called |LIBRARY_ARENA| which will give you the arena used by 
jextract to generate the bindings (although, I see that constant is 
currently package-private, so probably not accessible). So, at least in 
the common case of jextract-generated code, something along the lines of 
what you want to do seems already possible.

If you did not use jextract, but created your own bindings manually, the 
same approach could in principle be replicated: there’s an arena for the 
entire library - and you can access it in order to allocate, 
reinterpret, etc. Is there a specific reason as to why you think this 
approach is not viable in your case? If so, we’re genuinely interested 
in knowing more about your code.

Cheers
Maurizio

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240923/991ff54c/attachment-0001.htm>