On Thu, 2009-11-19 at 11:27 +1100, Dan wrote: > On Wed, 18 Nov 2009 22:46:35 +0000, Tom Wright > <[email protected]> wrote: > > Um, > > I don't know all of the background of this issue but surely a > better option would just be to fix libexif? > > > > As mentioned in my original email, I'm willing to look into the > problem, including libexif - *if* that is where the problem is. I > haven't had anyone reply yet with a 'yes, this is most certainly in > libexif'. My C skills are quite protozaic. I've already tried running > f-spot in valgrind, and it blew up immediately. I assume I'd have to > write a simple test app in C, and run that in valgrind. While this in > itself isn't outside my capabilities, actually finding the problem > might be. Also I have extremely little free time these days - I have a > 16-month-old, who takes up all my free time. > > And all the while, f-spot is still unusable. Pointing upstream doesn't > help end-users. In cases where there are long-standing upstream bugs > with no resolution in sight, it is perfectly valid to implement a > work-around. Or maybe market f-spot along the lines of "manage tens of > photos at once" :)
Libexif (and the other metadata dependencies we currently have) will be dropped: http://weblog.savanne.be/183-photo-support-for-taglib We're going to switch to the fully managed Taglib# once it's ready, which should eliminate at least that part of the leaking. More eyes on this is always welcome, we tend to lose memory in quite a few places, some very non-trivial. Ruben _______________________________________________ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
