Closed Bug 686307 Opened 9 years ago Closed 8 years ago

site memory leak related to bad JS code; lots of useless shapes and slots. Containment necessary.

Categories

(Core :: JavaScript Engine, defect, major)

8 Branch
x86
Windows 7
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 687935

People

(Reporter: fscussel, Unassigned)

References

()

Details

(Whiteboard: [MemShrink:P2])

Attachments

(3 files)

6.59 KB, application/octet-stream
Details
6.81 KB, application/octet-stream
Details
6.24 KB, application/octet-stream
Details
Attached file about memory.maff
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a2) Gecko/20110909 Firefox/8.0a2
Build ID: 20110909042004

Steps to reproduce:

[MemShrink] Whenever I leave firefox running with this site open: http://globoesporte.globo.com/futebol/times/gremio/ for one or more days and I come back in the next morning.


Actual results:

It leaks JS memory a lot (> 300mb, about:memory output attached) and it just keep raising and raising for as long as I keep firefox running without restarting.
Severity: normal → major
Whiteboard: [MemShrink]
Hardware: x86_64 → x86
Attachment #559893 - Attachment mime type: text/plain → application/octet-stream
Comment on attachment 559893 [details]
about memory_17-32_12_09_11.maff

After some more hours, keep increasing leak...
Attachment #559893 - Attachment description: After some more hours, keep increasing leak... → about memory_17-32_12_09_11.maff
What happens if you close the website? Is all the memory freed?
(In reply to Marco Castelluccio from comment #4)
> What happens if you close the website? Is all the memory freed?

correct.
I don't know what the deal is with the shape memory usage.

The large number of object-slots suggests they're adding entries to some global array and never removing them or something, which is of course something they can easily do....  The fact that the memory is released on page unload further supports this.
Summary: JS memory leak → JS memory leak; seem to be ending up with lots of shapes and slots, few objects
Just to make sure, minimizing memory in about:memory doesn't change the numbers, right?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: JS memory leak; seem to be ending up with lots of shapes and slots, few objects → site memory leak; seem to be ending up with lots of shapes and slots, few objects
(In reply to Boris Zbarsky (:bz) from comment #6)
> I don't know what the deal is with the shape memory usage.
> 
> The large number of object-slots suggests they're adding entries to some
> global array and never removing them or something, which is of course
> something they can easily do....  The fact that the memory is released on
> page unload further supports this.

Yes, I believe mozilla must implement some sort of control over that, even if the site was poorly coded the final user will never know about it and will end up with a crashing browser, there must be some sort of firewall against that leak.
> there must be some sort of firewall against that leak.

The solution to that is content processes.  That way the renderer can in fact crash without affecting the rest of the browser.

The other option is arbitrary caps that break web apps (e.g. limit the size of your gmail inbox), which does not seem desirable.
with proper programming (and probably it's not easy) I believe it´s possible to identify when a site was poorly coded, ie, some array that keeps increasing and increasing without changes in rendered page (which I believe is associated with your first proposal of contect processes).
Yes, but an array increasing and increasing without rendering changes does not necessarily imply a bug in the page.  It might be a bug, or it might be the page not showing you all your mails because you're writing an e-mail right now, not looking at the inbox.  Again, that's the gmail case.  There are lots of other use cases where you can't tell.
that's why I've said it wouldn't be easy, but it certainly must be fixed somehow. It's a known problem firefox increasing memory after a few days running, perhaps some bad coded pages like that one with a leaking memory in JS is the cause. The regular user would never guess what site is eating all the memory, so some sort of detecting/control is necessary.
> The regular user would never guess what site is eating all the memory

_That_ we can certainly fix, since we definitely have that information.  Perhaps we need the equivalent of the slow script dialog for sites using lots of heap.
if you can detect it to do a popup asking the user then there's the option to replace that popup with some sort of page reload. Because if when you reload the page all the JS leak is gone. Perhaps do it in a way that the user will never know that the site was leaking memory, like a refresh without all the paging going blank and the back again like the regular refresh.
Reloading the page generally leads to dataloss (after all, the whole point is that the page has a bunch of data in memory that it cares about, and the reload will lose that data!).
I am not a programmer, but I did learn Delphi and javascript by myself some 15 years ago. An easy workaround to fix this problem would be:

-> Firefox take note of the memory consumption of the full page when ended loading.

-> Firefox keeps watching every loaded site for memory increases.

-> When that page gets X times bigger than initial time, firefox reload the page in a way transparent to the user and without loosing any data present in the page (let's say you were writing an email).
There are a bounch of options to avoid dataloss, some I can think of:

1) Check if there´s user data written in that page (fields for entering data)

2) After initial load of the page, only reload if there were no user induced changes in that page (like filling a form, clicking a button, etc etc) for some time (X minutes, X hours). The OP site is a good example, I do nothing in it (because it is a soccers news website) and it keeps eating up and eating up memory. It could certainly be reloaded transparently without my knowledge.

3) Perhaps some way of reloading just the JS components of the site, not all the page.

As I've said I'm no programmer, so I'm a little limited in the proper coding. But those are my ideas for a quick fix, and as I've said the ideal would be some detecting complex mechanism that would know when a site is just adding data to a an array that produces nothing.
Losing data the page has in memory is losing data.  Just because it's not in a form control doesn't mean it's not user data.

Seriously, you can't reduce memory usage without dropping some of the data the page was holding.  The problem is that we have no way to tell which of that data the user cares about.  Figuring that out is equivalent to solving the halting problem.
Seriously Boris, your pessimism is annoying, I'm trying to give ideas the best I can and you just say nothing will work (which I hardly believe), so let's see your ideas to solve the problem, or you just want the problem to stay there and mark as "impossible to fix" ?
if an human can detect that the size of a website keeps increasing while nothing in the pages changes than a good programmer certainly can turn that into code. Just because you don't come up with a solution don't put pessimism in everything.
A human can't detect that.  They have no way to know whether the page will actually use the data it has in memory in the future.

A human can of course jump to a conclusion that the data will never ever be used in the future.  But they might well be wrong a lot of the time.

And yes, I think the problem you want to fix is unfixable.  To fix the problem that I think _is_ fixable (memory exhausting bringing down the browser), I already pointed out the preferred solution in comment 9.

Now there _is_ another issue here, which is why we have so many shapes here.  That seems wrong to me, and needs someone from the JS team to look into it.  The chances of that seem slim given the amount of noise in this bug....
Can't detect? I went to about:memory, checked that OP website was using 50mb of memory. After a few hours, it was using 150mb. After some more hours, 250, 300mb. I just leave that site website open, don't click anything. The page doesn't change, no new info unless you reload. Very easy to me to detect that it's leaking memory. No changes in the website and memory increasing like mad. I don't see how you don't think humans can detect it.
well, I see, it's easier for you to say it's unfixable, even knowing that it's not up to you to fix it. That's called pessimism. I'm trying to help developers to find a way.
of course 99% of the firefox users can't to the steps involved in finding out which website is causing the browser to consume memory like mad. And that's exactly why this bug must be fixed, because even we all knowing that's it's not exactly a firefox bug (bad coded website, arrays increasing for nothing), it must be fixed because they can't control every website code quality.
I filed bug 687935 on the shape issue so we can actually track and fix it without getting sidetracked on the windmill-tilting.
Depends on: 687935
why is it necessary to open a new bug for the same reason?
Because this bug lost focus.  One bug per issue.
well to me the focus is "JS leaking memory". I don't see why there's a need for a new bug.
That's not a focus, that's a meta-description.  Focus would be "JS leaking memory due to causes X, Y, and Z" followed by three separate bugs on X, Y, and Z.
Whiteboard: [MemShrink] → [MemShrink:P2]
ok boris
Summary: site memory leak; seem to be ending up with lots of shapes and slots, few objects → site memory leak related to JS bad code; lots of useless shapes and slots. Containment necessary.
Summary: site memory leak related to JS bad code; lots of useless shapes and slots. Containment necessary. → site memory leak related bad JS code; lots of useless shapes and slots. Containment necessary.
Summary: site memory leak related bad JS code; lots of useless shapes and slots. Containment necessary. → site memory leak related to bad JS code; lots of useless shapes and slots. Containment necessary.
sorry I am from Brazil, english is not my primary language.
(As a rule of thumb, if Boris says something about Firefox, it's extremely likely to be true.  In this case I agree with him.)
(In reply to Nicholas Nethercote [:njn] (on vacation Sep 12--Oct 17) from comment #32)
> (As a rule of thumb, if Boris says something about Firefox, it's extremely
> likely to be true.  In this case I agree with him.)

Ok, as far as it's looked into it doesn't really matter to me if it's handled here or in the other bug thread. All I want is firefox users free of that insane memory leak (and I'm sure it happens with many websites not just the one i've identified).
As fun as this bug was, there's no point having it open as well as bug 687935.
Status: NEW → RESOLVED
Closed: 8 years ago
No longer depends on: 687935
Resolution: --- → DUPLICATE
Duplicate of bug: 687935
You need to log in before you can comment on or make changes to this bug.