On Tue, Sep 06, 2011 at 09:45:46PM +0200, Stephan Beal wrote: > 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! > > 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. :)
Hello Stephan, thank you. I also like paired malloc/free, but there are some cases that the magic of fork() and exit() allows having a cleaner and more efficient code by simply not pairing malloc/free. In this case, I did not benchmark anything; and I started this work because a public fossil repository was hanging the linux serving it in a machine with 512MiB of RAM, due to the big leak in annotate. I had forgotten requiring anonymous login for the links, and a crawler memorised lots of accesses to [annotate]. :) And the OOM killer successed two or three times, then the kernel hanged. I suspect that the OOM killer does not cope well with processes writing to a tmpfs, but I don't know who to ask about that. If anyone has any idea here, I'd be glad to listen! Bye, Lluís _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
