[Pkg-xen-devel] Bug#767295: xl: apparent memory leak

[Ian Campbell]

reopen 767295
thanks

The 4.4.1-4 release only included one related fix there are actually two
more:

        commit 379b351889a8f02abe30a06e2ce9ba8b381b91ab
        Author: Ian Campbell <ian.campbell at citrix.com>
        Date:   Thu Nov 6 13:00:31 2014 +0000
        
            tools: libxl: do not leak diskpath during local disk attach
            
            libxl__device_disk_local_initiate_attach is assigning dls->diskpath with a
            strdup of the device path. This is then passed to the callback, e.g.
            parse_bootloader_result but bootloader_cleanup will not free it.
            
            Since the callback is within the scope of the (e)gc and therefore doesn't need
            to be malloc'd, a gc'd alloc will do. All other assignments to this field use
            the gc.
            
            https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295
            
            Reported-by: Gedalya <gedalya at gedalya.net>
            Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
            Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
            Acked-by: Wei Liu <wei.liu2 at citrix.com>
        
        commit 8f4023dd7d77de7b2c1af77e86637202a33f948a
        Author: Ian Campbell <ian.campbell at citrix.com>
        Date:   Thu Nov 20 15:48:47 2014 +0000
        
            libxc: don't leak buffer containing the uncompressed PV kernel
            
            The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which
            is freed by xc_dom_release. However the various xc_try_*_decode routines (other
            than the gzip one) just use plain malloc/realloc and therefore the buffer ends
            up leaked.
            
            The memory pool currently supports mmap'd buffers as well as a directly
            allocated buffers, however the try decode routines make use of realloc and do
            not fit well into this model. Introduce a concept of an external memory block
            to the memory pool and provide an interface to register such memory.
            
            The mmap_ptr and mmap_len fields of the memblock tracking struct lose their
            mmap_ prefix since they are now also used for external memory blocks.
            
            We are only seeing this now because the gzip decoder doesn't leak and it's only
            relatively recently that kernels in the wild have switched to better
            compression.
            
            This is https://bugs.debian.org/767295
            
            Reported by: Gedalya <gedalya at gedalya.net>
            Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
            Reviewed-by: Wei Liu <wei.liu2 at citrix.com>

Which the actual leaks discovered here (of which the second is the far
larger).