Structure testing crashes the VM about jpassport

[boulder-on]

Sorry about that! I've added the annotation. I'll work on building the tests today (I normally just run them from the IDE).

[mknjc]

It would be great to have a complete test for this. I've tried to investigate the problem but encountered a few problems. First, it seems a "jpassport.annotations.Array" annotation is missing. Additionally, it looks like a part of the test build system is missing too.

[boulder-on]

I've gotten the maven files to a point where they find the test classes, but for some reason none of the test methods are found.

[mknjc]

but for some reason none of the test methods are found.

because your tests aren't public.

I've got it running. (Had to add the jpassport/pom.xml, remove the mem.h include, and fix the library discovery for Linux)
Without an attached debugger, the test completes normally. With a debugger, it shows your behavior.

I've added a bit of debug output and do agree, the MHType and the FunctionDescriptor are correct so Jorn Vernee's guess doesn't look right, I think the missing intensification is an artifact of the jvm having a debugger attached.

The call symbol offset looks interesting:
On Linux, the code crashes with a SIGSEGV on the symbol offset, and a quick look in the coredump showed: the library isn't loaded anymore at call time.

At the end of PassportFactory.loadMethodHandles the library shows up in /proc//maps but in PassportWriter.build it disappears after the call compiler.run

It looks like, the lifetime of the library is bound to the liveness of the LibraryLookup and not to any MethodHandle. So your library gets unloaded after a gc cycle caused by the compiler.

[boulder-on]

Sorry for making extra work for you. I've checked in the pom.xml that was missing and made the tests public. I'm still stumbling my way through learning some of the tools. I appreciate the help.

The behaviour is reproducible on Linux as well? And appears related to running with an attached debugger.

I just did a quick test and found that if I stored the LibraryLookup object in a static list in PassportFactory then the crash doesn't happen. Is this something I should be doing (a part of the module usage I missed)? Or do you feel the problem is elsewhere?

[mknjc]

Sorry for making extra work for you

no problem, I was interested in myself.

The behavior is reproducible on Linux as well?

Yes, I'm now sure the debugger and the javac call caused a gc cycle and this unloads the library.

Is this something I should be doing (a part of the module usage I missed)?

Yep, I didn't see it in any doc but you have to hold onto the LibraryLookup. Currently, the Library Lookup system gets changed (https://mail.openjdk.java.net/pipermail/panama-dev/2021-May/013684.html) and in the future, (openjdk-17) you need to keep holding onto a ResourceScope

[boulder-on]

Fixed now. Passing the Symbol to create the MethodHandle (instead of Symbol.address()) will ensure that the LibraryLookup is held and therefore not disposed of by the GC.