User-Agent: Mozilla/5.0 (X11; U; Linux i686; en; rv:1.8.1.14) Gecko/20080418 Epiphany/2.20 Firefox/2.0.0.14 Build Identifier: This happens both with 0.0.18 and with the latest trunk. Reproducible: Always Steps to Reproduce: I open a folder containing ~ 80 images (png and jpg) and start to change the image displayed by ristretto by using keybinding or by clicking on the thumbnails. Actual Results: THe memory usage climbs up to 180mo (it starts from 30 mo). Expected Results: It shouldn't. I'll attach a valgrind log as soon as possible.
Created attachment 1615 valgrind log This is the first time I use valgrind, please tell me if I did something wrong.
You did everything fine, except one minor (non-valgrind specific) issue. You should have compiled ristretto with debugging information. (./configure --enable-debug) Then it will be easier for me to discover where the memory-leaks are present.
Created attachment 1616 new valgrind with ristretto debugging symbols Done, I hope it's better now.
Hmm, not really. Could you run the following command from the source-dir? $ valgrind --log-file=valgrind-ristretto.log --leak-check=full --show-reachable=yes ./src/ristretto And try running it with the cache-size on 1MB. See if it still leaks then. (see the preferences dialog for this option)
Created attachment 1618 new valgrind log with 1mb cache Please tell me if I can improve something (more debugging symbols, more preferences tunning).
(In reply to comment #5) > Created an attachment (id=1618) [details] > new valgrind log with 1mb cache > > Please tell me if I can improve something (more debugging symbols, more > preferences tunning). > It is interesting to see that the leak which was present in the former log doesn't come forward in this log. Could you try it with a cache-size half of what it used to be, and test again? (see if the memory useage grows to the same extend as it did before, or if it stops at an earlier stage)
Created attachment 1619 with 32 mo cache Cache size in mb Maximum memory usage 64 ~ 200 mo 32 ~ 80 mo 1 ~ 30 mo Feel free to ask me any other information you need.
As far as I can see now, It is not really a memory leak but an invalid calculation of cache-size. I'll write a patch this evening. Btw, what's mo... we are just talking MegaBytes's or MebiBytes here, right?
mo (or Mo) is very common in France (it's used in the french translation of ristretto that's why I used this word. After reading some doc on Wikipedia, it seems that 1 Mo = 1 Mb, octet seems to be a french word (if wikipedia is correct).
(In reply to comment #9) > mo (or Mo) is very common in France (it's used in the french translation of > ristretto that's why I used this word. > > After reading some doc on Wikipedia, it seems that 1 Mo = 1 Mb, octet seems to > be a french word (if wikipedia is correct). > Hehe, as it's an octet, I suspect it to be MB instead of Mb (MegaByte instead of Megabit) ^_^. But thanks for the explaination.
I improved the cache calculation in ristretto a bit. It is still lacking some numbers so the number it uses to calculate the memory-usage is still around 50%. However, it does not seem to be a memory leak since the memory is nicely free-ed when the max cache-size is exceeded or the images are closed.
I'll close this bug since it is not a memory-leak.