Currently I am involved in a project which is utilizing the libvirt Java JNA bindings. I appreciate the work which has been done on these bindings, but they appear to be leaking memory. I have tested this at a few different versions on a few different platforms including libvirt-java-0.4.6 with libvirt-0.8.5.
After looking at the C API and bindings soure, the leak appears to be somewhat systemic and caused by JNA's handling of functions which return a char*. In particular, any method in the C API which returns a char* (which allocates memory) but is declared as a String in the Java bindings will leak the backing memory of the C implementation. My understanding of JNA is that only 'const char*' should be declared as a String. From the JNA documentation available at: https://jna.dev.java.net/javadoc/overview-summary.html#strings
"If the native method returns char* and actually allocates memory, a return type of Pointer should be used to avoid leaking the memory. It is then up to you to take the necessary steps to free the allocated memory. "
There are many methods in the the bindings which follow this pattern, to name few:
virConnectDomainXMLFromNative
virConnectDomainXMLToNative
virConnectGetCapabilities
virConnectGetHostname
JNA is tooling that is new to me though, so perhaps I am interpretting this incorrectly. Can anyone who is familiar with JNA and the libvirt API confirm these suspicions? Fixing those declerations would be fairly trivial, I can put together a patch if that would be helpful. Unfortunately I believe this change would break the ABI for essentially all existing applications which utilize the bindings. If that is not acceptable perhaps someone could propose a more elegant solution. Because String is declared as a final class, there does not seem to be any obvious options to preserve ABI compatibility, but perhaps I am missing something.
--
Jason Yellick
After looking at the C API and bindings soure, the leak appears to be somewhat systemic and caused by JNA's handling of functions which return a char*. In particular, any method in the C API which returns a char* (which allocates memory) but is declared as a String in the Java bindings will leak the backing memory of the C implementation. My understanding of JNA is that only 'const char*' should be declared as a String. From the JNA documentation available at: https://jna.dev.java.net/javadoc/overview-summary.html#strings
"If the native method returns char* and actually allocates memory, a return type of Pointer should be used to avoid leaking the memory. It is then up to you to take the necessary steps to free the allocated memory. "
There are many methods in the the bindings which follow this pattern, to name few:
virConnectDomainXMLFromNative
virConnectDomainXMLToNative
virConnectGetCapabilities
virConnectGetHostname
JNA is tooling that is new to me though, so perhaps I am interpretting this incorrectly. Can anyone who is familiar with JNA and the libvirt API confirm these suspicions? Fixing those declerations would be fairly trivial, I can put together a patch if that would be helpful. Unfortunately I believe this change would break the ABI for essentially all existing applications which utilize the bindings. If that is not acceptable perhaps someone could propose a more elegant solution. Because String is declared as a final class, there does not seem to be any obvious options to preserve ABI compatibility, but perhaps I am missing something.
--
Jason Yellick
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list