513860 - FF3.5 Hangs in xul.dll!NS_CycleCollectorForget2 on page with long table & DOM Events

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Mark]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; 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.1; en-GB; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)

Firefox freezes and becomes unresponsive for 15 to 30 seconds. Stack trace shows last call to xul.dll!NS_CycleCollectorForget2 during hang.

Tested Platforms: 
FF3.5 On WinXP-32Bit, Vista-32Bit, Win7-32Bit (untested on other platforms)
Core 2 Duo @ 2.8ghz, 3gb RAM.

Extensions/Addons: 
All Disabled

Reproducible: Always

Steps to Reproduce:
On a clean, recently booted system:
1. Download attached "testcase.zip".
2. Extract zip file to a folder.
3. Open FF3.5 with a blank tab, close all others.
4. Return to folder and double click on "index.php.html"
2. Open attached HTML file several more times in seperate tabs (2 to 4 works for me)
3. Attempt to interact with page content (eg, scroll up and down, click, highlight) for a period of 5 seconds to 5 mins.
4. Observe CPU usage and GUI responsiveness
Actual Results:  
Firefox becomes unresponsive for 15 to 60 seconds.

Expected Results:  
Increased memory usage as each tab is opened.
Slowdown during loading of tab but normal function after loading is complete.

The test case includes a lot of check box elements. This is not a regression of bug 346337. Test cases from this bug dont trigger the freeze. 

Sample Stack Trace from Process Explorer during hang:

xul.dll!gfxPDFSurface::gfxPDFSurface+0x2608
xul.dll!Hunspell_destroy+0x6ed7
js3250.dll!JS_PCToLineNumber+0x2fcd7
xul.dll!gfxASurface::CheckSurfaceSize+0x5f0
xul.dll!gfxRect::Corner+0xea4
xul.dll!NS_CycleCollectorSuspect2_P+0x63a7
xul.dll!NS_NewLocalFile_P+0x2285
xul.dll!gfxFontUtils::ReadCMAP+0x35ee
xul.dll!gfxASurface::CheckSurfaceSize+0x7212
js3250.dll!js_Invoke+0x447
js3250.dll!JS_UnlockGCThingRT+0x25c
js3250.dll!JS_GetReservedSlot+0x2d83
MOZCRT19.dll!expand+0x1167
js3250.dll!JS_GetScriptPrincipals+0x18
js3250.dll!JS_HashTableRawAdd+0x3e
js3250.dll!JS_HashTableAdd+0x60
xul.dll!gfxPDFSurface::gfxPDFSurface+0x265d
xul.dll!Hunspell_destroy+0x6efc
xul.dll!NS_StringSetData_P+0x5891
js3250.dll!JS_PCToLineNumber+0x2904b
xul.dll!NS_CycleCollectorSuspect2_P+0x7e49
xul.dll!gfxASurface::CairoSurface+0x7352
xul.dll!NS_InvokeByIndex_P+0x15b2
xul.dll!gfxTextRun::CopyGlyphDataFrom+0x1a96
xul.dll!NS_CycleCollectorForget2_P+0x67fc

Please note that most of the javascript in the test case is broken as it has been captured by a "File->Save Page As..." from our intranet. It still works to reproduce the bug though.

Comment 1

[Mark]

Attachment: Zipped HTML & JS files to reproduce bug

Comment 2

[Nickolay_Ponomarev]

Thanks for the report and sorry no-one got to you sooner.

I tried this with 3.6 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a5pre) Gecko/20100412 Minefield/3.7a5pre and was didn't have any hangs.

Can you reproduce on the most recent 3.6.x release? On a nightly build from mozilla-central <http://nightly.mozilla.org/>?

I don't think this stack trace is real, you need symbols to get a real stack, e.g.: https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg

Comment 3

[Mark]

Hi, thanks for the response.

That trace was produced from SysInternals Process Explorer so no, I guess its not a true stack trace. I think its just showing the byte offset into each DLL file the calls are being made to.

Anyway, I've just re-run the test case using Firefox 3.6.3 on Win7 64bit. The UI remains responsive and loading was fast even after opening 10 instances of the test page and interacting with all tabs. I've also not had any recent complaints about the bug come in from our users so I guess we can assume it was fixed/mitigated in 3.6.x.

I'm a bit reluctant to say resolved as I still see occasional pauses during garbage collection in my day to day browsing. However, the key complaint here seems to be gone. It does leave me wondering why garbage collection isn't scheduled differently though. Any links/discussion about this I could read?

Comment 4

[Nickolay_Ponomarev]

Okay, I'll resolve it as WFM then.

> Any links/discussion about this I could read?
bug 549533, bug 539532, but I'm not following that work closely.