[libvirt] Application using libvirt crashes when having concurrent TLS connections (gnutls problem)

[Thomas Treutner]

On Friday 09 October 2009 19:38:34 Bryan Kearney wrote:
> The Java bindings should now be pretty light weight. Are you seeing this
> in them? If so, spin up a bug and I will take a look.

It took me quite some time to get to the bottom of this, as I'm not a 
professional full time dev. From what I see now, the gnutls problem just 
stems from the fact that libvirt connections somewhat tend to pile up.
When does that happen? I looked into the libvirt-java and libvirt source, and 
to me (again, I'm just coding for fun), there are two obvious bugs in 
libvirt-java (I'm even ashamed I didn't see them for so long ;)), both in 
org.libvirt.Connect:

1) Connect.close()

The return value of  libvirt.virConnectClose(VCP) is never checked, so VCP is 
NULLed in *any* case. That means: If a connection couldn't be shut down 
because there are still references to it, it can *never* be shut down in the 
future, even when there are no more references, because the VCP is then NULL.


2) Connect.finalize()

This is just a minor annoyance: The status of the VCP is again not checked. 
Means if the connection was closed properly, and some time later the garbage 
collector runs, an ugly and more importantly unneccesary error message is 
printed to the console. There should be a check if the VCP != null or 
something more appropriate. 

Regarding finalize(), I read in "Effective Java" that one should never rely on 
finalize() for tearing down things, as it is completely uncertain *when* the 
GC may run. This thing went through my brain in random directions, but right 
now, I think it's just the API user's responsibility to call close(). 


kr,
tom