From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [PATCH]xend: fix dual destroy Date: Sun, 27 Jul 2008 21:55:13 -0600 Message-ID: <488D4321.5000908@novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Cui, Dexuan wrote: > After changeset 18030 and 18064 were checked in, I found some issues > when creating HVM domains with devices assigned: > > In XendDomainInfo.py, we have the call trace: the global function > create() => vm.start() => _constructDomain(). > In _constructDomain(), we invoke xc.test_assign_device() and when the > function fails (maybe because iommu=1 is not specified in grub entry > since iommu is 0 by defaut now; maybe because the device doesn't exist; > maybe because the device has been assigned, or something) we raise > VmError; > Then start() will invoke self.destroy() and re-raise the exception; > Next, the global create() will invoke vm.destroy() again; finally, > _cleanupVm() and "self.metrics.destroy()" will be invoked again. Here > when we execute metrics.destroy() for the second time, the deregister() > in XendAPIStore.py will complain: there is no such an element in the > dict __classes and a KeyError exception is raised! > > We can avoid the dual destroy by adding a check as follows. > Thanks. Finding the right place to destroy the metrics object made me quite nervous. Thought I had been through enough testing after c/s 18064 to have gotten it right :-/. Even more discouraging - xend still has a significant leak. Jim