2011/9/5 Lluís Batlle i Rossell <virik...@gmail.com> > Yesterday I achieved quite a working code, through the use of empty_blob > (to > overcome the assertion), changing some blob operations (solving some > leaks), and > freeing that allocated never freed. >
Hi, Lluís! A comment on your commit message: [ef8266b710] Leaf: Implementation of a linked list to solve the memory leak described in a TODO in e2ebb1f5cae8. This code is slower than having the memory leak, and at the end, it was not a big memory leak. Let's say, 10 byte per revision involved in a file annotate. If a file has 30000 revisions, it may go around 300KB then. For this leak to be noticeable ... (user: viriketo, tags: label_linkedlist) We must not forget that 10 bytes for us clients doesn't count the internal bytes used by the allocator to track the allocation (i'm guessing 4-16 per allocation, depending on the platform, though there are special-case allocators with only 1 bit/alloc overhead), so a 300k leak is probably twice that size in reality. Since i'm so pedantic when it comes to having matched malloc/free() pairs, i personally really appreciate your efforts on this. Even if it has no outward effect on most users, i always sleep better knowing that the software i use is all clean and tidy on the inside. :) Happy Hacking! -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
