From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V84fM-0002BD-Ih for qemu-devel@nongnu.org; Sat, 10 Aug 2013 04:37:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V84f8-0004iS-ED for qemu-devel@nongnu.org; Sat, 10 Aug 2013 04:36:52 -0400 Received: from mail-ee0-x22d.google.com ([2a00:1450:4013:c00::22d]:40300) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V84f8-0004iA-6y for qemu-devel@nongnu.org; Sat, 10 Aug 2013 04:36:38 -0400 Received: by mail-ee0-f45.google.com with SMTP id c50so2523451eek.4 for ; Sat, 10 Aug 2013 01:36:37 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5205FB70.9020003@redhat.com> Date: Sat, 10 Aug 2013 10:36:00 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1375998147-24292-1-git-send-email-alex@alex.org.uk> <1375998147-24292-14-git-send-email-alex@alex.org.uk> <5204BF28.6000800@redhat.com> <685383E9-AA6D-4CDC-883B-92229FF601D1@alex.org.uk> <5204FE82.6080802@redhat.com> <8ABC08A9-37FF-44FD-8B0A-4DB572569E0E@alex.org.uk> In-Reply-To: <8ABC08A9-37FF-44FD-8B0A-4DB572569E0E@alex.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] [PATCHv8 13/30] aio / timers: Add aio_timer_new wrapper List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: Kevin Wolf , Anthony Liguori , liu ping fan , qemu-devel@nongnu.org, Stefan Hajnoczi , MORITA Kazutaka , rth@twiddle.net Il 10/08/2013 00:57, Alex Bligh ha scritto: > There are a large number of users of qemu_free_timer (now timer_free). > > If someone does not call qemu_free_timer having called qemu_new_timer, > the timer sits there and basically does nothing. If you have called qemu_del_timer, it is a memory leak. If you haven't, you'll get almost the same crash you describe here: > If we go to the timer_init model, the timer will either be on the > stack or (more likely) inside some other struct on the heap, which > will likely have been freed. This means walking the timer list will > be dangerous. With heap-allocated timers, the timer will exist on the heap, but likely the opaque will not and you'll get a crash in the callback. > This seems to add a good deal of fragility. It is really the same. The disadvantage is that you will not have a hint of which timer was accessed erroneously (the callback is a useful hint). The advantage is that you cannot leak timers, and the crash happens deterministically as soon as the object is deleted (rather than only when the timer fires). Paolo