Closed
Bug 686307
Opened 13 years ago
Closed 12 years ago
site memory leak related to bad JS code; lots of useless shapes and slots. Containment necessary.
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 687935
People
(Reporter: fscussel, Unassigned)
References
()
Details
(Whiteboard: [MemShrink:P2])
Attachments
(3 files)
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.
Updated•13 years ago
|
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
Comment 4•13 years ago
|
||
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.
Comment 6•13 years ago
|
||
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
Comment 7•13 years ago
|
||
Just to make sure, minimizing memory in about:memory doesn't change the numbers, right?
Updated•13 years ago
|
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.
Comment 9•13 years ago
|
||
> 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.
Reporter | ||
Comment 10•13 years ago
|
||
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).
Comment 11•13 years ago
|
||
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.
Reporter | ||
Comment 12•13 years ago
|
||
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.
Comment 13•13 years ago
|
||
> 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.
Reporter | ||
Comment 14•13 years ago
|
||
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.
Comment 15•13 years ago
|
||
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!).
Reporter | ||
Comment 16•13 years ago
|
||
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).
Reporter | ||
Comment 17•13 years ago
|
||
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.
Comment 18•13 years ago
|
||
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.
Reporter | ||
Comment 19•13 years ago
|
||
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" ?
Reporter | ||
Comment 20•13 years ago
|
||
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.
Comment 21•13 years ago
|
||
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....
Reporter | ||
Comment 22•13 years ago
|
||
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.
Reporter | ||
Comment 23•13 years ago
|
||
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.
Reporter | ||
Comment 24•13 years ago
|
||
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.
Comment 25•13 years ago
|
||
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
Reporter | ||
Comment 26•13 years ago
|
||
why is it necessary to open a new bug for the same reason?
Comment 27•13 years ago
|
||
Because this bug lost focus. One bug per issue.
Reporter | ||
Comment 28•13 years ago
|
||
well to me the focus is "JS leaking memory". I don't see why there's a need for a new bug.
Comment 29•13 years ago
|
||
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.
Updated•13 years ago
|
Whiteboard: [MemShrink] → [MemShrink:P2]
Reporter | ||
Comment 30•13 years ago
|
||
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.
Reporter | ||
Comment 31•13 years ago
|
||
sorry I am from Brazil, english is not my primary language.
Comment 32•13 years ago
|
||
(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.)
Reporter | ||
Comment 33•13 years ago
|
||
(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).
Comment 34•12 years ago
|
||
As fun as this bug was, there's no point having it open as well as bug 687935.
You need to log in
before you can comment on or make changes to this bug.
Description
•