Closed Bug 841005 Opened 11 years ago Closed 8 years ago

Runaway memory use on CBS video page

Categories

(Web Compatibility :: Site Reports, defect)

Product:
Web Compatibility
Component:
Site Reports
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: bas.schouten, Unassigned)

References

(
URL
)

Details

(Whiteboard: [MemShrink:P3]) 

When a couple of seconds into the video and then pausing it, leaving it paused for about 24 to 48-hours in a background tab causes run-away memory usage inside JavaScript.

It was at 2.7 GB this morning for example, which needless to say caused a crash relatively soon after I started using Firefox this morning.

This so far reproduced 3/3 times for me.
Could you attach the output of about:memory ?
Whiteboard: [MemShrink]
For all we know this could be a leak in the page, so we definitely need the about:memory output.
MemShrink:P3 until we get about:memory data.
Whiteboard: [MemShrink] → [MemShrink:P3]
This is trivially reproducible on any machine as far as I can tell. I'm not sure why you need me to attach the about:memory and lose another browser session.

If this actually -isn't- reproducible for people I'll more than happily crash another browser and get the data.
Flags: needinfo?(bas)
> I'm not sure why you need me to attach the about:memory and lose another browser session.

We ask for this for three reasons.

1. Our presumption usually is that bugs like this aren't reproducible.  This is based on experience with hundreds of such bugs, reported by experts and non-experts alike.  Often the peculiarities of a user's configuration -- platform, extensions, profile, location on earth (*) -- contribute to seeing high memory usage.

(*) Some sites serve different content to different physical locations.

2. The core group of MemShrink consists of only five or so people, and only one of us works full-time on these issues.  Even if every issue like this was reproducible, if we had to reproduce all of them ourselves, we'd never be able to get through all our bugs.

3. By asking reporters to give us about:memory with their bugs, we establish a norm that memory bugs should be filed with about:memory reports attached.  This saves everyone time in the long run.
I've started up the steps to reproduce in Chrome, so we can maybe see if it is a page bug.
(In reply to Justin Lebar [:jlebar] from comment #5)
> > I'm not sure why you need me to attach the about:memory and lose another browser session.
> 
> We ask for this for three reasons.
> 
> 1. Our presumption usually is that bugs like this aren't reproducible.  This
> is based on experience with hundreds of such bugs, reported by experts and
> non-experts alike.  Often the peculiarities of a user's configuration --
> platform, extensions, profile, location on earth (*) -- contribute to seeing
> high memory usage.

Well, I did explicitly mention reproducibility. Otherwise I probably wouldn't even have filed it :).

> (*) Some sites serve different content to different physical locations.
> 
> 2. The core group of MemShrink consists of only five or so people, and only
> one of us works full-time on these issues.  Even if every issue like this
> was reproducible, if we had to reproduce all of them ourselves, we'd never
> be able to get through all our bugs.

I'm not sure about:memory is going to be of too much use here, it just shows the page's gc-heap and such being really big. The thing is, I could reproduce it now, attach an about:memory report, and if there's actually something that needs to be done for this bug (i.e. if the page isn't just doing something stupid), a JS team member would most likely -still- also have to reproduce it.

> 3. By asking reporters to give us about:memory with their bugs, we establish
> a norm that memory bugs should be filed with about:memory reports attached. 
> This saves everyone time in the long run.

This is a good guideline, except that often when you run out of memory the browser is taken down before you can get an about:memory view.

Having said that I've started the site again and will let you know next time firefox crashes, hopefully I can get to about:memory before it does :).
> I'm not sure about:memory is going to be of too much use here, it just shows
> the page's gc-heap and such being really big. 

That itself is an important data point!  That suggests that either the page itself is leaking, or that we're not gc'ing enough.  All you'd need to do now is see whether clicking "minimize memory usage" lowers the memory usage significantly, and we'll have diagnosed the problem.
(In reply to Justin Lebar [:jlebar] from comment #8)
> > I'm not sure about:memory is going to be of too much use here, it just shows
> > the page's gc-heap and such being really big. 
> 
> That itself is an important data point!  That suggests that either the page
> itself is leaking, or that we're not gc'ing enough.  All you'd need to do
> now is see whether clicking "minimize memory usage" lowers the memory usage
> significantly, and we'll have diagnosed the problem.

Last two times the browser went down before I could try, hopefully I'll be able to get there this time.

Is it particularly hard to limit a single page/compartment's memory usage so that a single page can't consume our entire address space? It's rather annoying to lose your session to something like this.
It hasn't grown too much yet but it's a lot bigger than it was and at this point it's looking like this:

│  │  ├──159.58 MB (28.00%) -- window(http://www.cbsnews.com/video/watch/?id=7421030n)
│  │  │  ├──156.69 MB (27.50%) -- js/compartment(http://www.cbsnews.com/video/watch/?id=7421030n)
│  │  │  │  ├───82.41 MB (14.46%) -- objects-extra
│  │  │  │  │   ├──66.09 MB (11.60%) ── arguments-data
│  │  │  │  │   ├──16.04 MB (02.81%) ── elements
│  │  │  │  │   └───0.28 MB (00.05%) ── slots
│  │  │  │  ├───72.14 MB (12.66%) -- gc-heap
│  │  │  │  │   ├──68.23 MB (11.97%) -- objects
│  │  │  │  │   │  ├──67.85 MB (11.91%) ── non-function
│  │  │  │  │   │  └───0.38 MB (00.07%) ── function
│  │  │  │  │   └───3.91 MB (00.69%) -- (6 tiny)
│  │  │  │  │       ├──2.30 MB (00.40%) ── unused-gc-things
│  │  │  │  │       ├──0.62 MB (00.11%) -- shapes
│  │  │  │  │       │  ├──0.30 MB (00.05%) ── dict
│  │  │  │  │       │  ├──0.25 MB (00.04%) ── tree
│  │  │  │  │       │  └──0.07 MB (00.01%) ── base
│  │  │  │  │       ├──0.49 MB (00.09%) ── scripts
│  │  │  │  │       ├──0.30 MB (00.05%) ── arena-admin
│  │  │  │  │       ├──0.13 MB (00.02%) ── type-objects
│  │  │  │  │       └──0.07 MB (00.01%) ── strings
│  │  │  │  └────2.14 MB (00.38%) -- (6 tiny)
│  │  │  │       ├──1.46 MB (00.26%) ── script-data
│  │  │  │       ├──0.45 MB (00.08%) -- shapes-extra
│  │  │  │       │  ├──0.19 MB (00.03%) ── dict-tables
│  │  │  │       │  ├──0.18 MB (00.03%) ── tree-tables
│  │  │  │       │  ├──0.05 MB (00.01%) ── compartment-tables
│  │  │  │       │  └──0.04 MB (00.01%) ── tree-shape-kids
│  │  │  │       ├──0.12 MB (00.02%) -- type-inference
│  │  │  │       │  ├──0.08 MB (00.01%) ── object-main
│  │  │  │       │  └──0.04 MB (00.01%) ── tables
│  │  │  │       ├──0.07 MB (00.01%) -- string-chars
│  │  │  │       │  ├──0.05 MB (00.01%) ── non-huge
│  │  │  │       │  └──0.02 MB (00.00%) ++ huge
│  │  │  │       ├──0.05 MB (00.01%) ── analysis-temporary
│  │  │  │       └──0.00 MB (00.00%) ── other-sundries
│  │  │  └────2.88 MB (00.51%) -- (4 tiny)
│  │  │       ├──1.24 MB (00.22%) -- dom
│  │  │       │  ├──0.58 MB (00.10%) ── element-nodes
│  │  │       │  ├──0.53 MB (00.09%) ── orphan-nodes
│  │  │       │  ├──0.10 MB (00.02%) ── text-nodes
│  │  │       │  ├──0.02 MB (00.00%) ── other [2]
│  │  │       │  └──0.01 MB (00.00%) ── comment-nodes
│  │  │       ├──0.84 MB (00.15%) ── style-sheets
│  │  │       ├──0.81 MB (00.14%) -- layout
│  │  │       │  ├──0.30 MB (00.05%) ── style-sets
│  │  │       │  ├──0.22 MB (00.04%) ── pres-shell
│  │  │       │  ├──0.12 MB (00.02%) -- frames
│  │  │       │  │  ├──0.05 MB (00.01%) ── nsBlockFrame
│  │  │       │  │  ├──0.04 MB (00.01%) ── nsTextFrame
│  │  │       │  │  ├──0.02 MB (00.00%) ── sundries
│  │  │       │  │  ├──0.01 MB (00.00%) ── nsPlaceholderFrame
│  │  │       │  │  └──0.01 MB (00.00%) ── nsInlineFrame
│  │  │       │  ├──0.06 MB (00.01%) ── style-contexts
│  │  │       │  ├──0.04 MB (00.01%) ── rule-nodes
│  │  │       │  ├──0.03 MB (00.01%) ── line-boxes
│  │  │       │  ├──0.02 MB (00.00%) ── pres-contexts
│  │  │       │  └──0.01 MB (00.00%) ── text-runs
│  │  │       └──0.00 MB (00.00%) ── property-tables
If you hit "Minimize Memory Usage", does it go down?
(In reply to Bill McCloskey (:billm) from comment #11)
> If you hit "Minimize Memory Usage", does it go down?

It does not, nor does a GC.
Over to tech evang, then; this is very likely a bug in the site.
Assignee: general → english-us
Component: JavaScript Engine → English US
Product: Core → Tech Evangelism
Thanks a lot for investigating, Bas!
(In reply to Justin Lebar [:jlebar] from comment #14)
> Thanks a lot for investigating, Bas!

No problem! Just out of curiosity, would it be possible for us to limit the maximum memory usage of a site/compartment? The end-user impact of this bug is a user's browser crashing on a site that does something stupid like this, which is still something I'd like to see not happen :).
> would it be possible for us to limit the maximum memory usage of a site/compartment?

I don't think this would be impossible in the post-CPG world, but it would be tricky to do right.  It might be worth doing, though; can you file a bug?
Is there anyone who has been able to reproduce that issue?
Assignee: english-us → nobody
Component: English US → Desktop
I left a CBS page in paused state open over night, and I don't see any runaway mem usage now.

Bas, what about you?
Flags: needinfo?(bas)
(It was paused in an ad rather than in an actual program, might matter)
See Also: → 1079823
I don't think this is still happening as far as I can tell.
Flags: needinfo?(bas)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.