On 12/28/2013 11:11 AM, Eric Blake wrote: > In datatype.c, virGetDomainSnapshot could result in the message: > > error: invalid domain pointer in bad domain > > Furthermore, while there are a few functions in libvirt.c that > only care about a virDomainPtr without regards to the connection > (such as virDomainGetName), most functions also require a valid > connection. Yet several functions were blindly derefencing the > conn member without checking it for validity first (such as > virDomainOpenConsole). Rather than try and correct all usage > of VIR_IS_DOMAIN vs. VIR_IS_CONNECTED_DOMAIN, it is easier to > just blindly require that a valid domain object always has a > valid connection object (which should be true anyways, since > every domain object holds a reference to its connection, so the > connection will not be closed until all domain objects have > also been closed to release their reference). > > After this patch, all places that validate a domain consistently > report: > > error: invalid domain pointer in someFunc > > * src/datatypes.h (virCheckDomainReturn, virCheckDomainGoto): New > macros. > * src/datatypes.c (virGetDomainSnapshot): Use new macro. > (virLibConnError): Delete unused macro. > > Signed-off-by: Eric Blake <eblake@xxxxxxxxxx> > --- > po/POTFILES.in | 1 - > src/datatypes.c | 18 +- > src/datatypes.h | 23 ++ > src/libvirt-lxc.c | 11 +- > src/libvirt-qemu.c | 18 +- > src/libvirt.c | 1055 +++++++++++++--------------------------------------- > 6 files changed, 284 insertions(+), 842 deletions(-) > ACK I was going to point out a couple patches ago about the usage of domain->conn->flags in a call followed by a conn = domain->conn and then usage of conn-> afterwards, but figured it'd be cleared up soon enough... It was! :-) John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list