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