[Libtorrent-devel] Unaddressed memory issue

Josef Drexler josef at ttdpatch.net
Tue Jan 8 20:32:48 UTC 2008


On Jan 8, 2008, at 9:04 PM, In Incognito wrote:
> I ran valgrind on the newly compiled rtorrent/libtorrent.
>
> ==5961== ERROR SUMMARY: 3061122 errors from 8 contexts (suppressed:  
> 52 from 1)
> ==5961== malloc/free: in use at exit: 576,825 bytes in 229 blocks.
> ==5961== malloc/free: 146,820 allocs, 146,591 frees, 13,357,268  
> bytes allocated.
> ==5961== For counts of detected errors, rerun with: -v
> ==5961== searching for pointers to 229 not-freed blocks.
> ==5961== checked 850,956 bytes.
>
> allocs is greater than frees, according to the summary.

That is not generally a problem, so long as the memory is still in  
use when the program exits and it isn't a leak (which refers to now- 
unused memory that was forgotten to be de-allocated). However,

> ==5961== 160 bytes in 5 blocks are definitely lost in loss record 8  
> of 26
> ==5961==    at 0x40057F5: operator new[](unsigned)  
> (vg_replace_malloc.c:195)
> ==5961==    by 0x40CE9BC:  
> torrent::ProtocolExtension::generate_toggle_message 
> (torrent::ProtocolExtension::MessageType, bool) (extensions.cc:136)

This is an actual memory leak, all 160 bytes of it. Thanks for  
reporting this, I know how to fix it.

Note that valgrind won't notice memory used for transferring files,  
since that memory isn't allocated, but is simply using mmap to map  
files into the process's address space, even though that memory is by  
far the largest amount used by rtorrent, which may be surprising.

-- 
Josef Drexler
josef at ttdpatch.net





More information about the Libtorrent-devel mailing list