[Xen-devel] [PATCH 0 of 3] xl: free allocations made at top level

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

xl: free all allocations made at the top level

The following series makes "xl list" free of memory leaks (as reported
by valgrind) subject to two exceptions outlined below.

Although we may not care about many memory leaks in xl since the
commands are short lived I think it is important that we be able to
use xl to validate the libxl does not leak and/or that users of libxl
can be written which do not leak.

I've not extensively tested all possible xl commands so it is possible
that this series may expose a latent double free etc.  create,
destroy, console and list seem OK.

The series applies after Ian Jackson's series consisting of
    [PATCH 1/2] libxl: const-correctness for libxl_uuid2string
    [PATCH 2/2] xl: support "xl list <domain>"
which was posted to the list yesterday.

I used a version of valgrind which I have patched to understand the
PRIVCMD_HYPERCALL ioctl on /proc/xen/privcmd. It currently understands
exactly one sysctl (XEN_SYSCTL_getdomaininfolist). I will post the
patch shortly and imagine I will be expanding it as I test other xl
commands etc.

I ran the test with the
  --leak-check=full --show-reachable=yes --track-origins=yes
options to valgrind and there are two leaks remaining:

==7040== 8 bytes in 1 blocks are still reachable in loss record 1 of 2
==7040==    at 0x4022249: calloc (vg_replace_malloc.c:467)
==7040==    by 0x40616A3: hcall_buf_prep (xc_private.c:242)
==7040==    by 0x4062306: xc_sysctl (xc_private.h:177)
==7040==    by 0x4059F61: xc_domain_getinfolist (xc_domain.c:254)
==7040==    by 0x403FDBF: libxl_list_domain (libxl.c:496)
==7040==    by 0x8054B2E: main_list (xl_cmdimpl.c:3005)
==7040==    by 0x804B2FB: main (xl.c:76)
==7040== 
==7040== 4,096 bytes in 1 blocks are still reachable in loss record 2 of 2
==7040==    at 0x40220F6: memalign (vg_replace_malloc.c:581)
==7040==    by 0x4022153: posix_memalign (vg_replace_malloc.c:709)
==7040==    by 0x4061110: xc_memalign (xc_private.c:804)
==7040==    by 0x40616D8: hcall_buf_prep (xc_private.c:250)
==7040==    by 0x4062306: xc_sysctl (xc_private.h:177)
==7040==    by 0x4059F61: xc_domain_getinfolist (xc_domain.c:254)
==7040==    by 0x403FDBF: libxl_list_domain (libxl.c:496)
==7040==    by 0x8054B2E: main_list (xl_cmdimpl.c:3005)
==7040==    by 0x804B2FB: main (xl.c:76)

These are the hypercall argument buffers which libxc allocates, locks
into memory and stores in TLS using pthread_setspecific.

The memory should be freed on thread exit (libxc supplies a destructor
to pthread_key_create) but since xl isn't actually using threads it
never occurs.

I'm not sure that is really necessary to avoid these leaks (other than
to provide an empty base line for future work). They are pretty benign
since they are allocated exactly once per thread and I'm reasonably
happy that in a user of libxc/libxl which used threads they would
actually end up getting freed at the appropriate point.

If there were a way to tell valgrind not to worry about these
allocations that would be nice, as would a palatable workaround which
could be used in xl but I can't find anything suitable. For example
calling pthread_exit() at the end of main() causes leaks from the C
runtime so that is out. Creating a thread to do the body of the work
(with main just doing pthread_join and returning the result) doesn't
pass the palatable test IMHO

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel