On Mon, Aug 10, 2009 at 01:27:06PM +0200, Chris Lalancette wrote:
> All,
> I've been doing some testing of the virConnectRef() function, and as far as
> I can tell, it's busted. Here's the simple example program I'm using:
Its not really virConnectRef - the entire connection ref-counting setup
is broken - a virDomainPtr takes a reference on a virConnectPtr too and
that's not working correctly either AFAICT.
> #include <stdio.h>
> #include <stdlib.h>
> #include <libvirt/libvirt.h>
> #include <unistd.h>
>
> int main(int argc, char *argv[])
> {
> virConnectPtr conn;
>
> conn = virConnectOpen(NULL);
> printf("type is %s\n",virConnectGetType(conn));
> virConnectRef(conn);
> virConnectClose(conn);
> virConnectClose(conn);
> return 0;
> }
>
> When compiling and running this program, I get a segfault during the *second*
> virConnectClose(). The crash comes in the remote_internal driver, because the
> first virConnectClose() actually freed up the remote_internal private memory,
> and now the second one comes along and accesses a NULL pointer. I think this
> actually points to a bug in virConnectClose(); we shouldn't be running the
> ->close() callbacks on the drivers until we are going to be really closing up
> the driver, i.e. we should move all of the ->close() callbacks into
> virUnrefConnect(). Is that the right way to fix this?
We should just remove virUnrefConnect() completely. It is fundamentally
wrong for that to be separate from virConnectClose(), since there are
also places that call virUnrefConnect () directly which won't be releasing
the private data
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list