Pkg xen devel - Nov 2014 - Bug#767295: xl: apparent memory leak

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).

Processing commands for control at bugs.debian.org:
> reopen 767295
Bug #767295 {Done: Bastian Blank <waldi at debian.org>} [xen-utils-4.4]
xl: apparent memory leak
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions xen/4.4.1-4.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
767295: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295
Debian Bug Tracking System
Contact owner at bugs.debian.org with problems