On Thu, Feb 5, 2009 at 12:14 PM, Carlos Garnacho <[email protected]> wrote: > On jue, 2009-02-05 at 11:24 +0200, Tshepang Lekhonkhobe wrote: >> 2009/2/5 Martyn Russell <[email protected]>: >> > Tshepang Lekhonkhobe wrote: >> >>> What I meant was the RES column in top, just to be clear. >> >>> >> >>> I anyways ran $ valgrind --leak-check=full --show-reachable=yes >> >>> --leak-resolution=high -v /usr/libexec/trackerd >> >>> >> >>> and go the following output, and I don't know what it says: >> >>> >> >>> ==6792== LEAK SUMMARY: >> >>> ==6792== definitely lost: 36 bytes in 1 blocks. > > These are the bytes that valgrind consider leaked for sure > >> >>> ==6792== indirectly lost: 120 bytes in 10 blocks. > > And this is not freed memory pointed by freed/leaked pointers. > > Actually, these 2 "leaks" aren't such, since it's the XDG directories > cache in glib. > >> >>> ==6792== possibly lost: 43,872 bytes in 84 blocks. > > Valgrind couldn't guess whether 43Kb were leaked or not, it could be > interesting knowing where does that come from, but it's probably all > these operations with pointers in parsing/stemming, and inside > sqlite/qdbm which are confusing valgrind. > >> >>> ==6792== still reachable: 6,253,647 bytes in 26,607 blocks. > > And this is the legitimate memory that trackerd had allocated, around > 6MB
Wow, that's a little! Thanks for free education. I now wanna play some more with valgrind... -- my place on the web: floss-and-misc.blogspot.com _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
