From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roger Pau Monne Subject: Re: Libxenstore memory leak on static compile Date: Wed, 12 Sep 2012 16:03:51 +0100 Message-ID: <5050A457.7070201@citrix.com> References: <1347461790.24226.56.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1347461790.24226.56.camel@zakaz.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 Campbell Cc: Andres Lagar-Cavilla , Ian Jackson , xen-devel List-Id: xen-devel@lists.xenproject.org Ian Campbell wrote: > On Wed, 2012-09-12 at 14:44 +0100, Andres Lagar-Cavilla wrote: >> When statically compiling libxenstore.a, the USE_PTHREAD define is not >> applied. This results in cleanup_{pus/pop} being no-ops. cleanup_p* >> are used throughout xs.c:read_message to free malloc'ed objects. >> >> In short, libxenstore.a will leak memory when reading xenstore >> messages. OOM killer awaits. >> >> This could be solved by either turning on USE_PTHREAD for .a >> compilation (which, N.B. will not actually link libpthread but instead >> produce an object archive that needs to be eventually linked to >> libpthread.so), or by replacing cleanup_p* by proper free calls. > > The reason for the non-pthreads static library was so that you could > build tiny statically linked xenstore clients against tiny libcs (like > uclibc) to have things small enough to fit in e.g. your installer initrd > or in your "guest tools" package. > > It used to be that uclibc didn't have a pthreads library. Maybe this > has changed though (Roger, CCd, would know). Yes, uclibc added a pthread library back in 2002: http://mailman.uclinux.org/pipermail/uclinux-dev/2002-March/007613.html > We don't seem to use pthread_cleanup_push/pop very extensively, so I > think using proper free calls is probably the way to go? > > Using that pthread facility as a cheap and nasty GC seems a bit wrong to > me anyhow. > > Ian. >