822045 - Memory leak and crash with test case for bug 497732 when extensions are present

Status: RESOLVED WONTFIX

(Core :: XBL, defect)

Description

[Duncan Loveday]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

Steps to reproduce:

(1) Disable or uninstall all extensions. On a windows 7 platform, run the test case for bug 497732 three times with 100 repetitions each time (requires popups to be allowed). Observe the memory size of the firefox.exe process using the windows task manager.
(2) Repeat step (1) with at least 1 extension installed and enabled. I tried Firebug and some others.


Actual results:

In step 1 the memory usage of the process rises during the tests but falls back to somewhere close to its initial value shortly afterwards - good.

But in step 2 the memory usage of the process rises significantly and does NOT fall back to its initial value later. After 4 tests with 100 repetitions each my firefox.exe was over 1G in size. On the fifth attempt the process exit and the crash reporter appeared.


Expected results:

The memory usage in step (2) should be about the same or only slightly higher than in step (1). It appears as if some memory is allocated but not freed when the popups are opened and closed.

Comment 1

[Duncan Loveday]

Better name

Comment 2

[Scoobidiver (away)]

Can you provide the crash ID from about:crashes?
Does it happen in Nightly (http://nightly.mozilla.org/)?

Comment 3

[Duncan Loveday]

Crash ID http://crash-stats.mozilla.com/report/index/bp-d37072df-8072-40ec-99e5-22cc72121216

Comment 4

[Duncan Loveday]

Similar behaviour in the nightlies, crash ID http://crash-stats.mozilla.com/report/index/bp-3a4fe420-26f1-4661-a8e0-6fc252121216 using 20.0a1 (2012-12-15)

Comment 5

[Duncan Loveday]

Before we all get too excited - could it be that the memory leak and resulting crash are in the extension rather than Firefox itself ? The two I addons I have tried are "AsYouWish" (https://github.com/brettz9/asyouwish) and Firebug.

If it can be shown that the problem is with the addon itself we can close this as invalid and I can go and raise an issue with the author of the addon.

Comment 6

[Duncan Loveday]

I think the nightly build is actually somewhat worse in these tests. With one or more extensions enabled both 17.0.1 and the nightly leak memory and eventually crash though subjectively it seemed to me that the nightly grew in size and crashed more quickly.

With extensions *disabled* I ran a single test using 1000 repetitions in 17.0.1 and it took 200.518 seconds. Memory use started at 130M. During the test it climbed to around 600M with occasional spikes up to 1G. After the test it fell back to 350M. There were occasional GC pauses evident during the test when the memory size was reduced.

Doing the same with the nightly, memory started at 144M and climbed rapidly to about 1.4G and then it crashed, crash ID http://crash-stats.mozilla.com/report/index/bp-8333eab4-6dcb-496e-84cb-05a9b2121216.

Comment 7

[Scoobidiver (away)]

The three crash reports contain no exploitable information.
Can you provide a stack trace using Nightly (see https://developer.mozilla.org/docs/How_to_get_a_stacktrace_with_WinDbg)?

Note: you should update your graphics drivers: https://support.mozilla.org/kb/upgrade-graphics-drivers-use-hardware-acceleration

Comment 8

[Duncan Loveday]

Sorry to say I am not having much luck with WinDbg. I got as far as installing it and entering the first lot of commands, downloading the symbols, entering the second lot of commands, clicking "Go" on the debug menu to fire up the process. It opens the firefox window but then just seems to hang. The last few lines of the debug console window are as below. Has it stopped on a break point or something ?



ModLoad: 75f90000 75f9a000   C:\Windows\system32\LPK.dll
ModLoad: 75bc0000 75c5d000   C:\Windows\system32\USP10.dll
ModLoad: 75eb0000 75f5c000   C:\Windows\system32\msvcrt.dll
ModLoad: 76590000 771da000   C:\Windows\system32\SHELL32.dll
ModLoad: 762c0000 76317000   C:\Windows\system32\SHLWAPI.dll
ModLoad: 77360000 77400000   C:\Windows\system32\ADVAPI32.dll
ModLoad: 77760000 77779000   C:\Windows\SYSTEM32\sechost.dll
ModLoad: 776b0000 77751000   C:\Windows\system32\RPCRT4.dll
ModLoad: 74c70000 74e0e000   C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\COMCTL32.dll
ModLoad: 76430000 7658c000   C:\Windows\system32\ole32.dll
ModLoad: 749f0000 749f9000   C:\Windows\system32\VERSION.dll
(ce8.10ac): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=0012fb08 edx=775a7094 esi=fffffffe edi=00000000
eip=7760054e esp=0012fb24 ebp=0012fb50 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!LdrpDoDebuggerBreak+0x2c:
7760054e cc              int     3
1:027> help
       ^ Syntax error in 'help'

Comment 9

[Scoobidiver (away)]

There are a few breakpoints at the beginning so go on.
Once done, attach the log to this bug.

Comment 10

[Duncan Loveday]

Attachment: WinDbg output with addon enabled

I got it now. Attached WinDbg log with attachment enabled. The browser didn't crash when running on the debugger - it hung.

Comment 11

[Duncan Loveday]

Attachment: WinDbg output with addon disabled

Attaching a similar windbg output for the crash in the nightly with addons *disabled*.

Do we need to create any extra bug reports ? There seem to me to be two or three issues

(1) Memory leak in both 17.0.1 and trunk when addons are enabled.
(2) Memory leak in trunk only when addons are disabled.
(3) Crash in both 17.0.1 and trunk when memory size exceeds some limit.

Comment 12

[Duncan Loveday]

I should add that both the debug files were done with a clean profile apart from a single addon "AsYouWish" in the first test.

Comment 13

[Scoobidiver (away)]

Out-of-memory (not enough memory available) and memory leak (memory not freed) are two different things.
I see an OOM XBL crash when the add-on is enabled (retained signature) and a CSS crash when the add-on is disabled.
I let experts decide whether extra bugs are required.

Comment 14

[Duncan Loveday]

> Out-of-memory (not enough memory available) and memory leak (memory not freed) are two different things.

Understood, however this test must surely show a memory leak. It is not reasonable to suppose that 1G or more of memory is actually required to run these tests. The memory used accumulates when the browser has no obvious reason to need more which is the hallmark of a leak.

Comment 15

[Duncan Loveday]

For my money the most concerning aspect here is the memory leak in the trunk builds only with a clean profile, noted in comment 11 point 2. Perhaps that ought to have its own bug as it is a regression which the other two points noted in that comment are not.

Comment 16

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.