From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] tools/libxl: Improvements to libxl-save-helper when using valgrind Date: Fri, 11 Apr 2014 14:25:16 +0100 Message-ID: <5347ED3C.4080209@citrix.com> References: <1397152331-16769-1-git-send-email-andrew.cooper3@citrix.com> <21318.56947.346171.333514@mariner.uk.xensource.com> <5346DF73.3050705@citrix.com> <21319.52411.915176.220179@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21319.52411.915176.220179@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Ian Campbell , Xen-devel List-Id: xen-devel@lists.xenproject.org On 11/04/14 12:06, Ian Jackson wrote: > Andrew Cooper writes ("Re: [PATCH] tools/libxl: Improvements to libxl-save-helper when using valgrind"): >> On 10/04/14 19:09, Ian Jackson wrote: >>> Andrew Cooper writes ("[PATCH] tools/libxl: Improvements to libxl-save-helper when using valgrind"): >>>> * The destroy() function has been modified to be less antisocial. >>> Why ? Who calls the destroy function ? It's even less appropriate to >>> destroy this thing now that it's allocated statically. >> Only on manual calls to xtl_logger_destroy(), which don't check for >> NULLness of the function pointer before calling it. > This logger is never destroyed, though, is it. Correct > When you say "manual > calls" you don't mean the end user. I mean the owner of the logger explicitly calling "xtl_logger_destroy()" on it. > And there are no such calls on > this logger. Correct. > > The reason I provided a function which calls abort() is that in case > someone did foolishly try to destroy it, it produces a better stack > trace. I suppose that is reasonable. There is nothing which prevents some library code from attempting to destroy the logger in xch. The original 'antisocial' comment was when I tried to actually destroy the logger in the hope that it would free() the memory it allocated, before finding that it didn't work and having to look deeper for the leaked allocation. I shall respin a v4 leaving this in. ~Andrew