[bzr] Firefox plugin eats a lot of memory

Please remove all docklets and confirm again. It will be near impossible
to track down unless we narrow the search area a bit.

On Wed, 2009-05-27 at 19:42 +0000, Bernhard wrote:
> ** Attachment added: "debug-mem.txt"
> http://launchpadlibrarian.net/27214072/debug-mem.txt
>

Yeah, sorry I forgot to add that I removed CPU docklet and weather docklet and I had the same problem. So it is my current impression that it has nothing to do with docklets. The memory increase happens without any dependecies of gnome-do, it just sits and does nothing while memory increases. I know it's difficult to track down, I hope some further testing might give some more info.

I just tested and found that I get a 10MB spike each time I change the interface (and the Memory is not released later, it just piles up). So by switching the interface 15 times I can easily get to 200MB.

I correct my last statement: the 10MB hike does not occur when I switch interface but when I open and close (especially close) the preferences window.

I tested a bit more and I found that the memory increase also occurs with other interfaces like Classic or Mini, not just with docky.

On Thu, 2009-05-28 at 07:42 +0000, Bernhard wrote:
> I tested a bit more and I found that the memory increase also occurs
> with other interfaces like Classic or Mini, not just with docky.
>
That sounds like it could be a leak in some plugin's update methods?
Closing the preferences window will reload the Universe. What plugins
do you have enabled? If you disable all of them, do you still see this
behaviour?

I think I found the problem: it's the firefox plugin. There is no memory hike if that one is switched off. I will assign this to do-plugins.

I haven't seen this, i'll take a look though.

How many bookmarks do you have approx?

I have 60 bookmarks. I don't think it's the number of bookmarks.

I've got the same problem. Same symptoms, after some hours the memory use of gnome-do is up to several 100 MBs. I used the mono heap-shot profiler to capture a heap dump. See the attached file.

From what I can see there, it really looks like the firefox plugin being the culprit.

Here's a screenshot from HeapShot

Can confirm this with
gnome-do 0.8.2+dfsg-0~9.04~ppa3
gnome-do-plugins 0.8.2+dfsg-0~9.04~ppa3.

Also, since the latest gnome-do-plugins update, the Firefox plugin isn't working for me.

I get this in debug:
Firefox.PlacesItemSource "Firefox Places" encountered an error in UpdateItems: Object reference not set to an instance of an object.

All the bookmarks show up as "Firefox Bookmark Directory" folders and pulling them up gives this in the debug:
Firefox.PlacesItemSource "Firefox Places" encountered an error in ChildrenOfItem: Object reference not set to an instance of an object.

Same happens to me with the latest version 0.8.2.

It was consuming 600MB when i realized there was a problem and found this entry. As soon as i unchecked the firefox plugin it went back to +-30MB.

Could anyone test the branch I've linked and let me know if that fixes the memory issues with the FF plugin?

Yes, it works much better. I might get re-indexing spikes of 0.5 MB with ff-mem-fix, but much better than the 10 MB spikes in current trunk.

correct, it will spike but this is due to the copying of the ff db
file. But after indexing, the memory goes back down, no?

On Sat, Sep 5, 2009 at 4:33 AM, Bernhard<email address hidden> wrote:
> Yes, it works much better. I might get re-indexing spikes of 0.5 MB with
> ff-mem-fix, but much better than the 10 MB spikes in current trunk.
>
> --
> [bzr] Firefox plugin eats a lot of memory
> https://bugs.launchpad.net/bugs/381064
> You received this bug notification because you are a bug assignee.
>
> Status in GNOME Do Plugins Project: In Progress
>
> Bug description:
> Since rev 1195 I feel like docky leaks a lot more memory. It goes up to 300MB if I wait 2 hours. I will attach a debug of events during which the memory usage went from 40MB to 130MB.
>
> EDIT: after further testing, it seems like the firefox plugin (bzr of May 27) is the problem.
>

Not all the way down: I had something like

17MB after first indexing
19MB after second
19.5MB after third
20MB after fourth
20.5MB after fifth....

and so on. But this is really just a snapshot, I didn't do any long-term tests yet.

Bernhard, I noticed that too, but I found this isn't actually caused by Firefox. If you disable all plugins you'll notice this same behavior. Not quite sure what's causing it, but it only happens upon opening and closing the preferences dialog (IE, _not_ when Do reindexes), so it shouldn't be a huge usability issue.

Is 0.8.2.1 out yet?

It's not in PPA, but it will be soon.

On Mon, Oct 12, 2009 at 10:22 PM, Parthiban Balasubramanian
<email address hidden> wrote:
> Is 0.8.2.1 out yet?
>
> --
> [bzr] Firefox plugin eats a lot of memory
> https://bugs.launchpad.net/bugs/381064
> You received this bug notification because you are a bug assignee.
>
> Status in GNOME Do Plugins Project: Fix Released
> Status in “gnome-do-plugins” package in Ubuntu: Confirmed
>
> Bug description:
> Since rev 1195 I feel like docky leaks a lot more memory. It goes up to 300MB if I wait 2 hours. I will attach a debug of events during which the memory usage went from 40MB to 130MB.
>
> EDIT: after further testing, it seems like the firefox plugin (bzr of May 27) is the problem.
>

This bug was fixed in the package gnome-do-plugins - 0.8.2.1+dfsg-1~ubuntu1

---------------
gnome-do-plugins (0.8.2.1+dfsg-1~ubuntu1) karmic; urgency=low

  * Upload from pkg-cli-apps SVN to get this new bugfix release into Karmic.

gnome-do-plugins (0.8.2.1+dfsg-1) UNRELEASED; urgency=low

  * New upstream release 0.8.2.1
   - Correctly find Banshee indexer
   - Fix firefox leak on Mono < 2.4 (LP: #381064)
   - Close SSH hosts file after reading
   - Session plugin now works on devicekit-disks (LP: #410079)
  * 02_fix_banshee_plugin.dpatch: Drop, no longer required. Errors will be
    shown on console if Banshee is not installed but these are non-fatal.
  * rules, control: Use mono-csc

 -- Iain Lane <email address hidden> Wed, 14 Oct 2009 10:50:09 +0100