[Update]

Further debugging I have found that the problematic objects are the "virConnectCredential" instances; these are created as part of the callback procedure. If I keep these instances from getting GC'ed, there are no issues.
Also, as part of testing with esx driver, I see two instances of "virConnectCredential" getting created (one for user name and another one for password). But both these instances seem to be backed by the same native pointer; is this expected?

Thanks & Regards
Sachin Soman

 


On Tue, Apr 23, 2019 at 5:20 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Tue, Apr 23, 2019 at 05:02:12PM +0530, Sachin Soman wrote:
> [Update]
>
> Instead of passing an auth callback to Connect, if I store the credentials
> in an INI file and pass the file path as authfile URI parameter, I dont see
> these errors.

That makes it sound like some kind of memory handling bug in the JNI
native calls. I looked the libvirt-java code for the auth callback
but I don't entirely understand what JNI requires here. Probably needs
someone who is more expert in JNI to take a look at the libvirt bindings
I'm afraid.

Regards,
Daniel
--
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|