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

[Bryan Kearney]

On 10/28/2009 05:00 PM, Thomas Treutner wrote:
> 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.

I am not checking it. I will take a look and send you a patch.

>
>
> 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.
>

Agree.. I should check that as well.

> 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().
>

Let me work on a patch and send it to you.

-- bk