GNOME Bugzilla – Bug 715198
Shotwell uses all memory
Last modified: 2014-09-30 19:25:51 UTC
---- Reported by shotwell-maint@gnome.bugs 2013-11-21 13:13:00 -0800 ---- Original Redmine bug id: 7709 Original URL: http://redmine.yorba.org/issues/7709 Searchable id: yorba-bug-7709 Original author: nick hewitt Original description: As soon as I open Showtwell my memory usage climbs. Eventually all RAM and Swap is used and shotwell crashes. Ubuntu 11.10 Core 2 Duo 2.0 Ghz x 2 Shotwell 0.15.0 I can see there was an issue with Aurora theme in 2011. Is this still the issue? How do I fix it? What is Aurora theme? ---- Additional Comments From shotwell-maint@gnome.bugs 2013-11-21 14:55:00 -0800 ---- ### History #### #1 Updated by Jim Nelson 4 days ago * **Status** changed from _Open_ to _Need Information_ We've had numerous reports in the past of problems with Shotwell and the Aurora theme. I highly recommend switching away from Aurora. You should be able to do that in System Settings -> Appearance. Please let us know if that fixes your problem! #### #2 Updated by nick hewitt 4 days ago Jim Nelson wrote: > We've had numerous reports in the past of problems with Shotwell and the Aurora theme. I highly recommend switching away from Aurora. You should be able to do that in System Settings -> Appearance. Please let us know if that fixes your problem! settings, appearance. theme is Ambience(default). I am using a vanilla install of Ubuntu 13.10. Original post of 11.10 was wrong. Everything was working ok when on the lat LTS. Not sure if it was a Shotwell or Ubuntu update that caused the issue --- Bug imported by chaz@yorba.org 2013-11-25 21:36 UTC --- This bug was previously known as _bug_ 7709 at http://redmine.yorba.org/show_bug.cgi?id=7709 Imported an attachment (id=261487) Imported an attachment (id=261488) Unknown Component Using default product and component set in Parameters Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
I observed that when browsing photos in full view memory usage rises each time I switch to the next photo. Going back to photos already loaded before doesn't increase memory usage. It appears memory used for showing photos is not being released as soon as the photo is no longer shown. This was observed on Ubuntu 14.4 and Ubuntu 14.4.1 with Shotwell 0.18 and also 0.18.1 from the PPA. Previously on this system with Ubuntu 12.4, shotwell worked well without showing this memory leak.
*** Bug 737083 has been marked as a duplicate of this bug. ***
*** Bug 737390 has been marked as a duplicate of this bug. ***
*** Bug 736451 has been marked as a duplicate of this bug. ***
I had on other tickets asked for more information. I now have a grasp as to why this is occurring. Let me look at this today and tomorrow and see if I can put together a patch.
Pushed to master, commit aad834 It would be helpful to me if people having this problem could pull from master and try out on their system. I believe this memory problem has been responsible for a number of Shotwell issues.
On my computer this happens with pictures in .jpg. Imported directly from a recent panasonic camera - nothing fancy. Here is data for one of the pictures, shown by the file-browser: Type: Image (image/jpeg) Size: 6,5 MB (6.488.576 bytes) Location: /home/user/Pictures/2014/09/03 Volume: unknown The files is on the local hard-disk. The pictures have not been edited or changed. The memory is not released - quick enough on my computer. As a test, now, I just kept shotwell opened an observed the System Monitor in order to find out if the memory is released at all. My finding: It takes 3 minutes (!) before the memory is releases on my computer. This can be reproduced on my computer. Obviously, if you watch photos you can easily browse through a lot of photos in 3 minutes. Especially if you watch out for a specific picture - so no wonder, that shotwell chrashed frequently, for me. Don't hesitate to ask for more information.
(In reply to comment #6) > Pushed to master, commit aad834 > > It would be helpful to me if people having this problem could pull from master > and try out on their system. I believe this memory problem has been > responsible for a number of Shotwell issues. This solves my issues. This is what I did: I build from the latest master. (clone git) Result: The memory footprint never goes beyond 800MB even when browsing very fast through a pile of pictures. By the way: Browsing through the bugs on bugzilla.gnome.org it seems that there could be several duplicates of this bug. I am looking forward to the next release. :-) Thanks a lot!
(In reply to comment #6) > Pushed to master, commit aad834 > > It would be helpful to me if people having this problem could pull from master > and try out on their system. I believe this memory problem has been > responsible for a number of Shotwell issues. I added the daily-build ppa, and was offered the new version as an update. I still saw a steady increase in memory usage, until a crash occurred at 2.4 GiB.
@Michael Hendry: The bug-fix has been pushed to master very recently (1 hour ago). It would be surprising if the ppa already provides builds that contain this fix. I recommend to wait 24 hours - or at least to make sure that the patch has been included at build time.
(In reply to comment #10) > @Michael Hendry: The bug-fix has been pushed to master very recently (1 hour > ago). > It would be surprising if the ppa already provides builds that contain this > fix. I recommend to wait 24 hours - or at least to make sure that the patch has > been included at build time. Sorry, this is unfamiliar territory for me! I don't feel confident about doing a complete build myself, so I'll wait for 24 hours and try again.
Christian: The three minute delay is definitely indicative of the old caching strategy. The new code is much more conservative in terms of number of photos cached and how long they're kept in memory. Also, if you could point out which tickets you think are duplicates (or simply mark them as duplicates yourself), that would be most helpful. Michael: Yes, give the PPA a day. (In fact, the update may be ready in the next few hours.) I've pushed some tweaks to the original change, but I believe any of the new changes should solve your issues. If not, I'll take a closer look.
(In reply to comment #12) > Christian: The three minute delay is definitely indicative of the old caching > strategy. The new code is much more conservative in terms of number of photos > cached and how long they're kept in memory. > > Also, if you could point out which tickets you think are duplicates (or simply > mark them as duplicates yourself), that would be most helpful. > > Michael: Yes, give the PPA a day. (In fact, the update may be ready in the > next few hours.) I've pushed some tweaks to the original change, but I believe > any of the new changes should solve your issues. If not, I'll take a closer > look. Thanks, Jim. That seems to have done the trick, in that Shotwell has been running for a quarter of an hour on a cold-started computer for the first time since I upgraded to 0.20. Memory use went up gradually to a maximum of 380 MiB, with heavy CPU usage - up to 80% - but now (some 17 minutes since I started Shotwell) it's sitting at 228.3 MiB and 0%. I'm still puzzled by the fact that waiting an hour or so after the first crash of the day was enough to get Shotwell running before the latest fix. From a position of total ignorance about the internal workings of Shotwell, I could only explain this on the basis that some process was left running after the first crash, which eventually finished off the tidying-up job that was causing the runaway memory usage, and shotwell didn't bother to do this job. [I don't expect an explanation - just thinking aloud, and thankful to be able to work on my images again!] Michael
Possible duplicate: "Random crashes while browsing the library" Bug 734251
Alas, that looks to be a different problem. Michael, without going into the gory details, what you're describing is consistent with the (faulty) caching behavior coded into Shotwell. Shotwell's memory usage will fluctuate as images are accessed due to the large memory size of an decoded images, but it should always "settle" over time if left inactive.