[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é <berra...@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 :| >
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
