Error PInvokeStackImbalance in runtime

[mknezevic]

Hi,

I have a .NET project in which uses a dll created from a jar file using IkvmReference. The project builds successfully and the corresponding dll is created. However, during runtime I'm getting the error:

Managed Debugging Assistant 'PInvokeStackImbalance' Message=Managed Debugging Assistant 'PInvokeStackImbalance' : 'A call to PInvoke function 'IKVM.Runtime!IKVM.Runtime.JNI.JNIVM+LibJvm+Set_JNI_GetDefaultJavaVMInitArgsDelegate::Invoke' has unbalanced the stack. This is likely because the managed PInvoke signature does not match the unmanaged target signature. Check that the calling convention and parameters of the PInvoke signature match the target unmanaged signature.'

Any thoughts?

I use:
Visual Studio 2022
.NET Framework 4.8.1
IKVM 8.6.2

The jar that I use is grobid-core version 0.7.1 https://github.com/kermitt2/grobid/tree/0.7.1

[wasabii]

Can you try downgrading a few versions? I hit this recently as well, and haven't had a chance to do much about it.

[mknezevic]

Sure! I will try and report the progress.

[AaronRobinsonMSFT]

My guess is this is an issue only for x86 due to incorrect calling convention.

ikvm/src/IKVM.Runtime/JNI/JNIVM.cs

Line 49 in 3024f42

delegate void Set_JNI_GetDefaultJavaVMInitArgsDelegate(JNI_GetDefaultJavaVMInitArgsDelegate func);

If so, the solution is to adorn the delegate with UnmanagedFunctionPointerAttribute.

[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
delegate void Set_JNI_GetDefaultJavaVMInitArgsDelegate(JNI_GetDefaultJavaVMInitArgsDelegate func);

[wasabii]

Yeah. That makes sense. I don't know why it wasn't caught during tests though. Initializing JNI is pretty well covered. That's why I was thinking it had to be a little bit deeper at least.

Unless you mean x86, as in not x64.

[wasabii]

This whole section is sort of a place holder for now, too, btw. Needed a way to do calls from JNI code into IKVM, in a few cases where OpenJDK C libraries would do so but not have a JNIEnv on hand.

End game is to have libjvm use hosting APIs to get back into .NET, thus making it possible for people to embed IKVM as they would embed a real JDK.

[wasabii]

Aaactually. I need to think through this more. I think JNI exports on Win32 are supposed to be stdcall. I didn't add JNICALL in jvm.cpp. Maybe that's the issue.

[wasabii]

So I think the Set_ methods (since I'm making them just be JNI-like methods) should be JNIEXPORT/JNICALL, so stdcall on Windows. However, the delegates to the callbacks should probably be cdecl, since they're not actually JNI-like methods, but just function pointers to implement the functionality behind the JNI methods.