From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V48w6-0000Dr-KT for qemu-devel@nongnu.org; Tue, 30 Jul 2013 08:21:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V48w1-00047p-Oh for qemu-devel@nongnu.org; Tue, 30 Jul 2013 08:21:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V48w1-00047e-Gx for qemu-devel@nongnu.org; Tue, 30 Jul 2013 08:21:49 -0400 Date: Tue, 30 Jul 2013 14:21:43 +0200 From: Igor Mammedov Message-ID: <20130730142143.10a5734d@nial.usersys.redhat.com> In-Reply-To: <51F79CD8.7070807@siemens.com> References: <51F79CD8.7070807@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Error handling in cpu_x86_create List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel On Tue, 30 Jul 2013 13:00:40 +0200 Jan Kiszka wrote: > Hi Igor, > > just noticed by chance that error handling in cpu_x86_create is likely > broken after your changes. Any error after cpu = ...object_new() will > not properly release the CPU object again nor report NULL to the caller. > That means errors should slip through, no? And cpu_x86_init looks similar. Failure of object_new() in cpu_x86_create() is not checked since it should never fail. As for following error handling caller of cpu_x86_create(..., errp) should use errp to check for errors and release failed cpu. cpu_x86_init() that calls it has: === out: if (error) { fprintf(stderr, "%s\n", error_get_pretty(error)); error_free(error); if (cpu != NULL) { object_unref(OBJECT(cpu)); === similar code-path exists in pc_new_cpu() end goal is to replace cpu_x86_create() with just object_new(FOO_CPU), but that needs to x86 CPU subclasses and properties in place so we could remove/isolate legacy stuff to legacy hook. Did you hit any particular problem with current code? > > Jan >