After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 548633 - Metadata refresh leaks
Metadata refresh leaks
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: Metadata
git master
Other Linux
: Normal minor
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-08-20 11:47 UTC by Michael Monreal
Modified: 2009-06-22 06:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Monreal 2008-08-20 11:47:30 UTC
After starting the new banshee build, it started a metadata refresh. As I had gnome-system-monitor open at the time I could see banshee's memory usage grow... from about 50mb to 117mb. I have waited some time but this does not seem to be fixed by garbage collection etc.
Comment 1 Gabriel Burt 2009-06-02 22:59:12 UTC
Setting as minor since the refresh isn't something that runs every time.
Comment 2 Alexander Kojevnikov 2009-06-20 23:47:52 UTC
*** Bug 586498 has been marked as a duplicate of this bug. ***
Comment 3 Alexander Kojevnikov 2009-06-20 23:48:39 UTC
As indicated in duplicate bug 586498, the same happens when re-scanning the library.
Comment 4 Mike Rooney 2009-06-21 00:00:55 UTC
As I mentioned in the other report, these could be two different leaks; we don't know that the metadata refresh leak accounts for all the leakage of a rescan. How can I trigger a metadata refresh myself to compare the two in terms of memory leaks? Thanks!
Comment 5 Alexander Kojevnikov 2009-06-21 00:07:32 UTC
Reverting the summary.
Comment 6 Mike Rooney 2009-06-21 01:28:31 UTC
Okay, I've done a bunch of testing, the full report of which is in bug 586498. The conclusion is that they are separate bugs. The metadata specific part is that Banshee starts out consistently at 40MB of RAM (Resident/Writable), and after a metadata refresh goes to 350M, for a difference of 310M or 40Kb per track (8000 total). The rescan leaks an additional 20Kb of memory per track.
Comment 7 Alexander Kojevnikov 2009-06-21 06:24:42 UTC
I added a patch to bug 586498 that reduces the memory consumption during metadata refresh.
Comment 8 Mike Rooney 2009-06-21 07:27:16 UTC
The patch is a great improvement to metadata refreshes as well; the memory only increased 40-50MB instead of 310MB, so only 5-6KB per track. However it was a somewhat gradual increase which might indicate another smaller leak still existing.
Comment 9 Alexander Kojevnikov 2009-06-22 01:56:03 UTC
The patch from bug 586498 is committed.

I did more tests (with the patch). I modified banshee to run N subsequent metadata refreshes on startup. The memory usage increases after i-th refresh on a library with 2,100 songs are:

1: +21.4 MiB
2: +11.9 MiB
3:  +2.9 MiB
4:  -6.7 MiB

The last number suggests that the GC finally kicks in.

I then ran 100 metadata refreshes in a row. The result was +166.8 MiB, or +1.7 MiB per refresh.

I'm not sure if it's a leak or the GC is just being lazy. I have lots of RAM and GC is probably taking advantage of it.

I'm closing this bug as FIXED, feel free to re-open if you think it's not and have more information.
Comment 10 Michael Monreal 2009-06-22 06:43:16 UTC
"100 metadata refreshes in a row" meanins 100 refreshes of the whole library? If that's just +1.7 per run we should be fine at this point.
Comment 11 Alexander Kojevnikov 2009-06-22 06:48:22 UTC
(In reply to comment #10)
> "100 metadata refreshes in a row" meanins 100 refreshes of the whole library?
> If that's just +1.7 per run we should be fine at this point.

Yep, 100 refreshes of a library with 2,100 songs.