On 12/18/2012 08:14 AM, Benjamin Wang (gendwang) wrote:
> Now if the cable is unplugged and the application call virConnectClose to release connection, the code will enter into the error procedure, the connection
> Can't be released. I have changed the following two parts to fix this issue. Please give your comments:
> Changed Code1:
> int
> virConnectClose(virConnectPtr conn)
> {
> ...
>
> + if(NULL == conn) {
> + return 0;
> + }
>
> ...
>
>
> - if (!VIR_IS_CONNECT(conn)) {
> - virLibConnError(VIR_ERR_INVALID_CONN, __FUNCTION__);
> - goto error;
> - }
> ...
It's much easier to read patches that are produced by 'git diff' than by
open-coding the differences into your email. In particular, missing
context makes it hard to see where you are intending your patch to
apply. However, I will NACK this patch. NULL is never a valid
connection, and passing NULL must make the API return failure, not
success. The existing 'if (!VIR_IS_CONNECT(conn))' is sufficient to
check for an invalid passing of a NULL pointer.
>
> For libvirt java, there are similar issue. I have changed code as following in Collect.java. Please also give your comments.
> public int close() throws LibvirtException {
> int success = 0;
> if (VCP != null) {
> + try {
> success = libvirt.virConnectClose(VCP);
> processError();
> + }
> + finally {
> // If leave an invalid pointer dangling around JVM crashes and burns
> // if someone tries to call a method on us
> // We rely on the underlying libvirt error handling to detect that
> // it's called with a null virConnectPointer
> VCP = null;
> + }
Unfortunately, I'm not familiar enough with libvirt-java to know if this
patch makes sense.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list