After a while of running Nightly and Collusion on my OSX machine, I see *really* slow CC and GC cycles, causing interaction delays lasting 1-2 seconds, occurring every few seconds. GC duration would go over 2000ms and CC duration would climb up to 600-700ms at the worst. In about:compartments, there were a lot of active compartments from websites that were no longer open.
I'm currently on 13.0a1 (2012-03-08), but I had this problem the day before (7th) and had automatically applied an update since then.
The slow GC and CC seem to be due to memory leaks. Her Facebook compartment was over 100MB.
> After a while of running Nightly and Collusion on my OSX machine
No other extensions, right?
I just played with Collusion 0.16.2 on my Linux box in a clean profile of Nightly. I browsed to some news sites, opened and closed the Collusion page, and didn't see any compartment leaks.
I'm using this on an OSX if that makes any difference, with at least 30 other tabs open. The persisting compartments I'm seeing are from facebook, twitter and some news sites, and they persist after closing all tabs to that site and after GC has run
Thanks for bringing this to my attention.
Malini, are the memory leaks happening only while you have the Collusion UI open in a tab? Or does it persist after you close the collusion UI? Or does it happen even if you never open the UI page?
That will help me figure out what part of the extension code the memory leak might be in.
Ah, I believe I'm seeing this because I had a newssite that was using some facebook/twitter plug-in, and that might have made the compartment persist as mccr8 suggested to me.
I didn't activate the UI during the first run when I saw this. I just restarted my Nightly instance, closed the newssites, and now I don't see any unnecessary compartments, so I'm pretty sure it's because of fbconnect and what not.
> Ah, I believe I'm seeing this because I had a newssite that was using some facebook/twitter
> plug-in, and that might have made the compartment persist as mccr8 suggested to me.
Andrew, can you elaborate on what you think was happening here?
Facebook like buttons are put in a FB compartment, right? So you could close the FB page but still have FB compartments around.
Yeah, social network widgets are inserted using iframes, so it sounds like those weren't zombie compartments after all.
Please reopen if I got this wrong.
Well, she's still experiencing massive memory usage with the addon, and not experiencing it without the addon. That suggests something is wrong, though it sounds like reproducing it may be difficult.
> Facebook like buttons are put in a FB compartment, right? So you could close the FB page but
> still have FB compartments around.
Ah, yes. Were all the zombies pages with corresponding "like button" frames, or did you see zombies for content origins like nytimes.com or techcrunch.com?
(In reply to Andrew McCreight [:mccr8] from comment #9)
> Well, she's still experiencing massive memory usage with the addon, and not
> experiencing it without the addon. That suggests something is wrong, though
> it sounds like reproducing it may be difficult.
That could be related to the add-on's complexity and not necessarily memory leaks. Malini, can you post the contents of about:memory to see if anything stands out?
(In reply to Jorge Villalobos [:jorgev] from comment #11)
> (In reply to Andrew McCreight [:mccr8] from comment #9)
> > Well, she's still experiencing massive memory usage with the addon, and not
> > experiencing it without the addon. That suggests something is wrong, though
> > it sounds like reproducing it may be difficult.
> That could be related to the add-on's complexity and not necessarily memory
> leaks. Malini, can you post the contents of about:memory to see if anything
> stands out?
It would be great if we could get the pastebin we looked at yesterday. Something was extremely wrong; she was using 1.5gb of memory for relatively few compartments. GC times were upwards of 2s.
This add-on is not that complex. I'm re-opening because we have a preponderance of evidence that something was wrong. We can resolve incomplete if we can no longer reproduce.
Created attachment 605015 [details]
About:memory read out
I don't have the information from the previous occurrence, but I just ran into his again now. The problem here is that I've been running Nightly for over a day with the Collusion, Vimperator and Bugzilla tweaks add-on. I'm not sure if any of these are the contributors of this problem. I'll copy this profile and run it without these addons, and with collusion only to see what the problem is. It will most likely be a day or two before I'll see the problem!
I've attached the about:memory read out, will attach about:compartments and memchaser log
Created attachment 605016 [details]
Created attachment 605017 [details]
What tabs did you have open when you collected those readouts?
Also, the about:memory?verbose output would be useful.
Created attachment 605030 [details]
list of open tabs
Here's the list of open tabs. Unfortunately, I can't get the about:memory?verbose log for you now, I had to restart the browser
Okay, there are definitely zombie compartments in there, such as
I installed it, visited a few sites, then closed everything except bugzilla, gmail, and gcal. The copmartments from a twitter button and a news site were still up. Then I closed all my tabs except about:compartments. The twitter and news sites' compartments went away, but my bugzilla and Google compartments were still alive.
(In reply to Justin Lebar [:jlebar] from comment #20)
> J'accuse Vimperator.
Kris, can you verify this?
(In reply to Jorge Villalobos [:jorgev] from comment #21)
> (In reply to Justin Lebar [:jlebar] from comment #20)
> > J'accuse Vimperator.
> Kris, can you verify this?
I don't have anything to do with Vimperator anymore, so I don't have much to say on the matter. It certainly does have a lot of interaction with content and isn't well maintained, or at least wasn't in the year after I left the project, so the chances are good that it does leak.
Adding Vimperator dev.
Malini, can you verify that the leaks are gone after Vimperator is disabled?
Aha, yes, I can! Thanks for the find!
P3 per Memshrink.
The developer has been notified the listing will be downgraded next week if there's no acknowledgement on his side regarding this bug.
I'm working with Martin Stubenschrott, but my knowledge about zombie compartments is not that good. I will read some documentation to try to get an idea of the problem.
> I'm working with Martin Stubenschrott, but my knowledge about zombie compartments is not that good.
We're here to help if you still need it after reading the docs.
Ok, we seem to have takled at least one big memory leak regarding closed tabs here:
It's hard to say if that is everything, as of course the code base is quite huge. I still created a first beta version of the upcoming 3.4 version including this bug fix. Can anybody test, if it helps fixing the memory leak?
The XPI is here:
(I'd like some feedback before "officially" releasing a new version on AMo).
I couldn't get this version to leak, upon a cursory inspection. It seems a lot better. Malini should probably put it through its paces, though, if she has a chance.
I tried to upload the new version as 3.4 to addons.mozilla.org, but after the file has uploaded 100%, the page says "Validating vimperator-3.4.xpi" but that for at least 2h now. Is something broken on AMo?
The validator has been having problems recently. Please try again, and if the problem continues, please file a bug (https://bugzilla.mozilla.org/enter_bug.cgi?product=addons.mozilla.org) and attach the file you're trying to upload.
Actually, this is probably bug 739106.
Thanks for the info, I resubmitted 3.4 and it worked flawlessly now.
Memory leak appears to be fixed in Vimperator 3.4 so marking as fixed.