From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsBlz-0001y5-A9 for qemu-devel@nongnu.org; Fri, 20 Jul 2012 07:53:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SsBly-0000mC-3z for qemu-devel@nongnu.org; Fri, 20 Jul 2012 07:53:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsBlx-0000m8-RH for qemu-devel@nongnu.org; Fri, 20 Jul 2012 07:53:30 -0400 Message-ID: <500946AC.2040407@redhat.com> Date: Fri, 20 Jul 2012 13:53:16 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <4FFBD6F1.90403@redhat.com> <20120713091611.GC15503@stefanha-thinkpad.localdomain> <4FFFEF8E.5080705@redhat.com> <50000793.2020401@redhat.com> <5003CDC6.2040103@linux.vnet.ibm.com> <5003CE8B.20804@redhat.com> <500678F7.1030705@linux.vnet.ibm.com> <20120718135846.GE2294@redhat.com> <20120718153543.GK2294@redhat.com> <5007F167.3030602@redhat.com> <20120720113830.GH31455@redhat.com> In-Reply-To: <20120720113830.GH31455@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Anthony Liguori , Stefan Hajnoczi , Michael Tokarev , qemu-devel@nongnu.org, =?UTF-8?B?TGx1w61z?= , Blue Swirl , Stefan Weil , Hannes Reinecke , Wenchao Xia Il 20/07/2012 13:38, Daniel P. Berrange ha scritto: > There's two aspects to it. First we forbid use of malloc/free/realloc > in favour of an alternative set of APIs designed such that we can get > compile time errors when people don't check the result for NULL. > > http://berrange.com/posts/2008/05/23/better-living-through-api-design-low-level-memory-allocation/ > > This has been very successful in ensuring code checks for OOM correctly. > Second there is a mode in our test suites where you can run under > simulated OOM - it runs once to count the total set of mallocs in the > test, and then re-run it 'n' times failing each malloc in turn and > verifying that we correctly report the OOM error condition. Does it fail each malloc in turn, or does it fail each malloc "above X bytes" after the Y-th? Because the latter is what you actually get in practice, and it seriously hampers your recovery capabilities. Right now, we always use g_malloc and abort on failure, but we could replace it with g_try_malloc in specific large allocation cases, where large could even be not that large, for example around 64K. Paolo