516202 - Memory use grows steadily while MSDN pages are open, leading to OOM crash after a few days idle

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[Dean Kolosiek]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

This crash happens while sitting idle. Crash Reporter says there was a problem submitting the report.

Reproducible: Always

Steps to Reproduce:
1. Install Firefox. Don't change any settings.

2. Go to these pages in separate tabs:

     http://msdn.microsoft.com/en-us/library/hk61a712.aspx
     http://msdn.microsoft.com/en-us/library/k44daxya.aspx
     http://msdn.microsoft.com/en-us/library/t058x2df.aspx
     http://msdn.microsoft.com/en-us/library/hf9hbf87.aspx

3. Wait for the crash. It's usually 2 or 3 days, sometimes longer. It also happens on Vista 64.

Comment 1

[Tyler Downer [He/Him]]

Can you please give a stacktrace? https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report

Comment 2

[Dean Kolosiek]

I don't have time to mess with it now, I'm not a developer and I've already put in a lot of effort making it easy to reproduce.

Something I forgot to report is that Crash Reporter is not reporting it because the dump files are empty.

Comment 3

[Tyler Downer [He/Him]]

Does it happen in a new profile? if you do not help we won't be able to learn more and fix this. I am volunteering my time to help make this a useful report as well. So, I will close until more info is available.

Comment 4

[Dean Kolosiek]

Yes it happens in a new profile. I think I covered that in step 1. Firefox was never previously installed.

Apparently you didn't even try it.

I'll answer questions, but I don't have time to do what a developer should be doing.

Comment 5

[Tyler Downer [He/Him]]

Yes, actually, I did try this and did not get a crash. As I can not see the crash, the only way to get useful information is from you, using the steps given in the link in comment 1.

Comment 6

[Dean Kolosiek]

It has happened every time for me. I had even made a virtual machine to make sure it was reproducible.

I made another virtual machine that has never had Firefox on it to check it again. I'm waiting for it to crash.

Comment 7

[Dean Kolosiek]

It still crashes.

This time I noticed the commit size was constantly growing. Last night I saw it over 1.8 GB. Firefox was also using a surprising amount of CPU time.

Then I tried it in another virtual machine with 256MB RAM and in 12 hours got a low virtual memory dialog from Windows and another dialog that said A script on this page has been stopped due to a low memory condition.

Comment 8

[Marco Bonardo [:mak]]

We can't do anything without a stack trace.

Comment 9

[Jesse Ruderman on Windows]

This is a memory-use issue.  A crash stack trace would only tell us what we already know (cf bug 506771 comment 3).

What would help is figuring out which of our memory leak tools complains about MSDN, and/or making a reduced testcase.

https://wiki.mozilla.org/Performance:Leak_Tools

(This is specific to MSDN pages, right?)

Comment 10

[Wayne Mery (:wsmwk)]

Dean, are you able to get a leak report?

Comment 11

[Tyler Downer [He/Him]]

Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode or a fresh profile? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles

Comment 12

[Tyler Downer [He/Him]]

This bug has had the CLOSEME tag for several weeks and the date in the tag is far gone. If the reporter can still see this issue, Please retest with Firefox 3.6.x or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). Then please remove the closeme tag in the whiteboard, mark the bug against the proper version and comment on the bug.