Red Hat Bugzilla – Bug 441950
f-spot has serious memory leak
Last modified: 2009-01-09 01:22:07 EST
Description of problem:
When turning a bunch of photos right using the "Adjust the angle of the image to
straighten the horizon" button, f-spot keeps growing. The first time I really
noticed this, it was too late: f-spot crashed (or presumably, was killed by the
kernel) because it had gotten too large to fit in memory + swap.
One experiment I did:
Start f-spot, run ps -lC f-spot, adjust the angle of one photo, run ps -lC
f-spot again. The value in the SZ column grew from 47124 to 60327.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Import photos into f-spot
2.Double click (or select "Edit image") a photo
3.Click on Adjust angle button and adjust the angle
The memory footprint of f-spot keeps getting bigger.
Exiting and restarting f-spot regularly circumvents the problem but is hardly a
I've built 0.4.3.1 as a potential update for Fedora 8, while it's not in the
updates-testing repository yet, you can grab the RPM from
http://kojipkgs.fedoraproject.org/packages/f-spot/0.4.3.1/1.fc8/ would you
please be able to check if you can still reproduce the bug?
Did the 0.4.3-1 update fix the memory leak for you?
It is hard for me to test this.
The system I reported this for is a 32-bit laptop that now runs Fedora 9.
I have a Fedora 8 system at work, but it is 64 bits. And there if I try f-spot I get:
** (/usr/lib64/f-spot/f-spot.exe:11566): WARNING **: The following assembly referenced from /usr/lib64/f-spot/f-spot.exe could not be loaded:
Assembly: NDesk.DBus (assemblyref_index=9)
Public Key: f6716e4f9b2ed099
The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/usr/lib64/f-spot).
** (/usr/lib64/f-spot/f-spot.exe:11566): WARNING **: Could not load file or assembly 'NDesk.DBus, Version=220.127.116.11, Culture=neutral, PublicKeyToken=f6716e4f9b2ed099' or one of its dependencies.
Unhandled Exception: System.TypeLoadException: A type load exception has occurred.
$ rpm -q f-spot
However on my 64 bit Fedora 9 system (yet another system) with f-spot-0.4.3.1-2.fc9.x86_64, memory still seems to be growing. But since this system has 4 GiB of memory, it'll be a while before it hurts.
(In reply to comment #3)
> It is hard for me to test this.
> The system I reported this for is a 32-bit laptop that now runs Fedora 9.
> I have a Fedora 8 system at work, but it is 64 bits. And there if I try f-spot
> I get:
> $ f-spot
> ** (/usr/lib64/f-spot/f-spot.exe:11566): WARNING **: The following assembly
> referenced from /usr/lib64/f-spot/f-spot.exe could not be loaded:
> Assembly: NDesk.DBus (assemblyref_index=9)
> Version: 18.104.22.168
> Public Key: f6716e4f9b2ed099
> The assembly was not found in the Global Assembly Cache, a path listed in the
> MONO_PATH environment variable, or in the location of the executing assembly
This is reported as Bug 457662, in the mean time, 'yum install ndesk-dbus-glib ndesk-dbus' should fix the issue.
> ** (/usr/lib64/f-spot/f-spot.exe:11566): WARNING **: Could not load file or
> assembly 'NDesk.DBus, Version=22.214.171.124, Culture=neutral,
> PublicKeyToken=f6716e4f9b2ed099' or one of its dependencies.
> Unhandled Exception: System.TypeLoadException: A type load exception has
> $ rpm -q f-spot
> However on my 64 bit Fedora 9 system (yet another system) with
> f-spot-0.4.3.1-2.fc9.x86_64, memory still seems to be growing. But since this
> system has 4 GiB of memory, it'll be a while before it hurts.
I'll let the f-spot folks know, I think this might end up fixed as a result of their GSoC work (0.4.5 is said to be considerably faster and economical in certain situations). However, I doubt that f-spot 0.4.5 will make it into Fedora 8 (I can foresee an update when Mono 2.0 enters Fedora 9 though).
I installed those packages and was able to run f-spot on the Fedora 8 system (64 bit).
I still see an increase in size after each angle adjustment. But since I have only tried a few, it could still be the size stabilizes after a while.
In Fedora rawhide (F10 beta), f-spot has massive memory use. Importing <1Gbyte of jpegs from a camera and then browsing each one causes f-spot to grow to ~3.5Gbytes, pushing everything else out on my 4G machine.
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.