The default bug view has changed. See this FAQ.
Bug 728407 (leakychrome)

[Meta] Runtime leaks caused by chrome

NEW
Unassigned

Status

()

Firefox
General
5 years ago
3 years ago

People

(Reporter: smaug, Unassigned)

Tracking

(Depends on: 7 bugs, Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-kilimanjaro:-)

Details

(Whiteboard: [Snappy:P3])

(Reporter)

Description

5 years ago
The simple CC analyzer can be useful to find leaks, especially if the
leak cycle contains a document.
Install the addon (Bug 726346), load about:cc, 'Run cycle collector' and
after getting the log click 'Find Documents'.

Runtime leaks cause FF to use more memory and run CC slower.
OS: Linux → All
Hardware: x86_64 → All
Whiteboard: [MemShrink]
Version: unspecified → Trunk
(Reporter)

Updated

5 years ago
Depends on: 728414

Comment 1

5 years ago
I tried your add-on, but how long has 'Run cycle collector' to run before getting the log?
When I run the cycle collection, I see only 'Processing. Please wait...'.
(Reporter)

Comment 2

5 years ago
You need to run the very latest m-c builds. Bug 726346 is probably not yet in the latest Nightly.
Running CC takes usually <1s with that addon and processing the log takes perhaps 1-2s.
But if there lots of objects, processing may take a lot longer.

Comment 3

5 years ago
Doh, sorry, indeed I'm running the latest nightly not m-c build. I'll wait. Thanks. :)
(Reporter)

Updated

5 years ago
Depends on: 728426
Alias: leakychrome
(Reporter)

Updated

5 years ago
Depends on: 728549

Updated

5 years ago
Depends on: 728663
Depends on: 728669
Whiteboard: [MemShrink]
Depends on: 728577
No longer depends on: 728549

Updated

5 years ago
Depends on: 731567
Depends on: 734210
(Reporter)

Updated

5 years ago
Whiteboard: [Snappy]
(Reporter)

Comment 4

5 years ago
Added [Snappy], because most of the leaks increase CC times dramatically.
(Reporter)

Updated

5 years ago
Depends on: 737956
Keywords: qawanted
Olli, can you please add some example scenarios so that QA has more info to go on.
(Reporter)

Comment 6

5 years ago
So, use various functionality of Firefox, and run about:cc / cycle collector / find documents
occasionally to check if some documents show up in the cycle collector graph.
See https://bugzilla.mozilla.org/show_bug.cgi?id=728407#c0
(Reporter)

Comment 7

5 years ago
We should probably do similar testing for most common addons.
(Reporter)

Comment 8

5 years ago
Also, about:cc shows some possibly leaked documents after cycle collector run, it is good to
re-run cycle collector and find-documents to make sure that documents really stay there in the
cycle collector's graph
(In reply to Olli Pettay [:smaug] from comment #6)
> So, use various functionality of Firefox, and run about:cc / cycle collector
> / find documents
> occasionally to check if some documents show up in the cycle collector graph.
> See https://bugzilla.mozilla.org/show_bug.cgi?id=728407#c0

I spoke with Olli to clarify. Using various Firefox functions can include opening and closing menus, creating a bookmark, using a dev tool, opening bookmarks or history, etc.

The point of this exercise is to test various areas of the browser to discover leaks.
ccing Anthony for QA help with the investigation.
(In reply to Olli Pettay [:smaug] from comment #6)
> So, use various functionality of Firefox, and run about:cc / cycle collector
> / find documents
> occasionally to check if some documents show up in the cycle collector graph.
> See https://bugzilla.mozilla.org/show_bug.cgi?id=728407#c0

Is there any particular functionality I should focus my attention on? anything that is likely to showcase this bug more than others?
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #11)
> (In reply to Olli Pettay [:smaug] from comment #6)
> > So, use various functionality of Firefox, and run about:cc / cycle collector
> > / find documents
> > occasionally to check if some documents show up in the cycle collector graph.
> > See https://bugzilla.mozilla.org/show_bug.cgi?id=728407#c0
> 
> Is there any particular functionality I should focus my attention on?
> anything that is likely to showcase this bug more than others?

I think the request is more of an exploratory one where we don't know the areas of the browser that may be leaky. Turning the request around, what areas do we know to be leaky that QA can avoid testing?
(Reporter)

Comment 13

5 years ago
(In reply to Lawrence Mandel [:lmandel] from comment #12)
> Turning the request around, what
> areas do we know to be leaky that QA can avoid testing?
Look at the bugs this bug depend on.
Anthony, as Olli noted in comment 13, the dependent bugs contain areas that are known to be leaky within the product. Can you create a test plan that broadly covers other areas of the product? We can use the results to drive further investigations.
(In reply to Lawrence Mandel [:lmandel] from comment #14)
> Anthony, as Olli noted in comment 13, the dependent bugs contain areas that
> are known to be leaky within the product. Can you create a test plan that
> broadly covers other areas of the product? We can use the results to drive
> further investigations.

It's unrealistic to assume I can deliver on a request this broad. I've started an email thread with you, Lawrence, in this regard. I expect to work with you on a plan of action and then we will come back to this bug.
OK. Let's talk this out and come back with a reasonably scoped plan.

Updated

5 years ago
Depends on: 741700
Whiteboard: [Snappy] → [Snappy][MemShrink]
This has already been tagged (and then untagged) with MemShrink.  We generally don't tag meta bugs in MemShrink.
Whiteboard: [Snappy][MemShrink] → [Snappy]

Updated

5 years ago
Whiteboard: [Snappy] → [Snappy:P3]
Depends on: 744817
Depends on: 731875
No longer depends on: 744817
(Reporter)

Updated

5 years ago
Depends on: 745744
Depends on: 691537
Noming for k9o. I spoke with Olli, who said that preventing leaks is one of the best things that we can do to prevent unnecessary CC runs at this point.
Blocks: 746389
blocking-kilimanjaro: --- → ?
(Reporter)

Comment 19

5 years ago
Even more importantly, leaks make CC times bad.

Comment 20

5 years ago
While leaks are surely an important issue for k9o, I don't see any dependency bugs here that would affect the web apps runtime which has no Firefox chrome and no add-on support.
blocking-kilimanjaro: ? → -
(Reporter)

Updated

5 years ago
Depends on: 758894
(Reporter)

Updated

4 years ago
Depends on: 829300
(Reporter)

Updated

4 years ago
Depends on: 833429
Depends on: 839489
(In reply to Lawrence Mandel [:lmandel] from comment #16)
> OK. Let's talk this out and come back with a reasonably scoped plan.

Lawrence, I don't recall what was agreed upon here. Can you jog my memory and re-add qawanted to this bug if there's something needing our attention here? Thanks
Keywords: qawanted
Thanks for the ping Anthony. We documented the process we were to follow in https://wiki.mozilla.org/QA/Snappy/Chrome_Leak_Testing. 

I have an e-mail from Olli, Virgil and you from April with initial results that was never added to this bug. Here's the context that I have (newest first):

Olli: 

Compiler or OS memory management shouldn't affect to this stuff at all. These leaks are something that browser UI causes. And since browser UI isn't the same on all the platforms, the results may be different. For example, on OSX we don't have print preview.


Anthony:

Here's the results for Tier 1 on Windows 7, Mac OSX 10.6, ad Ubuntu 11.10. Let me know if A) you need QA assistance investigating the two issues found and B) you want us to retest on other platforms/tiers.

Hopefully this first run was useful to you.

Thanks


Virgil:

Hi Anthony,

Mihaela, Vlad and myself have performed chrome leak testing today on Firefox 14 Nightly and focused on tier 1 areas on Windows 7, Mac Os 10.6 and Ubuntu 11.10 32-bit.

We have followed the steps specified in: https://wiki.mozilla.org/QA/Snappy/Chrome_Leak_Testing
We have encountered two leaked document situations. Both of them being logged and listed already in the dependencies for bug 728407 :

- https://bugzilla.mozilla.org/show_bug.cgi?id=728426
- https://bugzilla.mozilla.org/show_bug.cgi?id=728663

We've added the OSs in the test plan under tier 1 results. Please lets us know if there is anything else we can help with.

Virgil
(In reply to Lawrence Mandel [:lmandel] from comment #22)
> Thanks for the ping Anthony. We documented the process we were to follow in
> https://wiki.mozilla.org/QA/Snappy/Chrome_Leak_Testing. 

Ah yes, thanks for the reminder Lawrence. Are there any next steps you want QA to take? Given this is now a P3 maybe it's now worth looking into at this time.
Like you said, this is now a lower priority. I don't think there's any need to do any additional testing at this time.
(Reporter)

Comment 25

4 years ago
Leak hunting should happen continuously.
I've found some leaks recently (Bug 839280 and Bug 833783).
Since not too many use tools like about:cc we don't catch chrome leaks easily.
(also, about:cc is rather awful addon. It does just the things I need.)
So, I hope we could figure out what to do with bug 839489 and get leak detection more
automatic.

Updated

4 years ago
Depends on: 850456
Depends on: 852996
Depends on: 852404
Depends on: 853859
(Reporter)

Updated

4 years ago
Depends on: 897751
Depends on: 912047
Depends on: 950165
You need to log in before you can comment on or make changes to this bug.