GNOME Bugzilla – Bug 115305
Binary attachments remain in memory after being written to disk
Last modified: 2009-08-15 18:40:50 UTC
As i was monitoring my processes with top, i discovered that, when downloading a message with a 15 Mb attachment, pan requires an additional ~15Mb from the beginning to the end of the dowloading. What is surprising is that, once the attachment is decoded and written do disk, the 15Mb are still allowed by pan. Deleting the message in the header pane releases these 15Mb from memory. This is quite puzzling to me ; anyway there are a few possibilities: - either it is a feature because the messages are expected to remain in pan's cache, and pan's cache is expected to be on memory, not on disk ; but this would be very unusual, at least to me - or it is the expected behaviour, but who whould expect 150 Mb of RAM to be necessary to download 10 x 15 Mb attachments ? - or it is a defect
Could you install valgrind, and run it on such a Pan session to look for leaks? I've been over the code again and again and can't find the problem.
OK, i followed your advice and ran: valgrind --leak-check=yes --leak-resolution=high --num-callers=12 --logfile=pan /usr/bin/pan Here are the actions i performed: - select another news server in the server menu - load a binaries newsgroup - filter all messages whose subject matches a certain string - read article A - download & save binary attachments for articles A & B - read article C - save binary attachment for article C Additional infos: - article A: 38 lines - article B: 208338 lines - article C: 292 lines I'm about to attach valdgrind's log file ; i hope this is enough for you to track this defect ; otherwise i'll do some more tests
Created attachment 17912 [details] Valgrind logfile #1
Using top and 0.14.2.91, I can't reproduce this. I followed your steps: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND Started pan: 342 charles 16 0 7776 7776 6032 S 0.0 0.1 0:00 0 pan Loaded a group with 35,000 articles: 342 charles 15 0 26736 26M 6308 S 0.1 0.6 0:00 1 pan Filter on subject: 342 charles 15 0 26808 26M 6340 S 0.8 0.6 0:00 1 pan Read a small article "a": 342 charles 15 0 31660 30M 6772 S 1.4 0.7 0:01 0 pan Saved articles "a" (small) and "b" (multipart mp3), note no jump: 342 charles 15 0 31952 31M 6788 S 0.1 0.7 0:02 1 pan read article "c" (small): 342 charles 15 0 31952 31M 6788 S 0.0 0.7 0:02 1 pan Deleted articles "a", "b", and "c": 342 charles 15 0 31952 31M 6788 S 0.1 0.7 0:02 1 pan The only jump I see is on reading article "a" -- there's no 10M jump during the decode of the multipart mp3... I guess the next step, assuming you're still at this email address after a year of my ignoring bug reports, is for you to try to reproduce the latest beta version of Pan.
Hey, Charles, it's a pleasure to hear from you again ! You're absolutely right, 0.14.2.91 behaves very well and you can for sure close this defect ! Cheers Nicolas