User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081206 Shiretoko/3.1b3pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081206 Shiretoko/3.1b3pre Every time I visit www.easynews.com and log in, then choose a usenet group with a lot of activity, the page loads, and then the browser stops responding completely. The pinwheel cursor shows up, and I have to "force quit". There is no crash report/no talkback page. Reproducible: Always Steps to Reproduce: 1. Load attached HTML file. 2. Watch Shiretoko stop responding. Actual Results: Shiretoko stops responding/hangs. Expected Results: Shiretoko continues responding/doesn't hang Saved the HTML from one of the pages that was causing the problem, and then loaded the HTML by itself (no javascript). Problem is still there. Tried disabling all add-ons, problem still occurs. Tried from a new profile, and the same thing happened. I have no idea what to look for in the HTML as the cause, or how to narrow this down any further. Will attach an HTML testcase to show the problem.

Can you try making a new profile and then setting javascript.options.jit.content to false in about:config and see if that helps?

Tried a new profile with javascript.options.jit.content to false, it didn't help. (I don't understand how that possibly could have, though, since it's hanging on HTML, not javascript--per my description that was the first thing I eliminated as a cause)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081206 Shiretoko/3.1b3pre ID:20081206042621 I see the hang too --> NEW and setting some flags

Okay, this is *STRANGE*. The HTML testcase attached does NOT cause the hang to occur (for me). However, by saving the HTML testcase to my desktop and THEN loading it, the problem shows up. (OR by visiting Easynews itself) I'm at a loss...

Can you please minimize the testcase if possible ?

(In reply to comment #6) > Can you please minimize the testcase if possible ? I don't believe that it's possible to minimize it. I tried removing approximately the first half, and there was only a very brief hang (2 seconds or so), and then the browser began to respond again. Then I tried removing only the second half and reached the same result, a very brief hang. It appears to me as though it's the size or quantity of HTML that triggers the issue.

Further experimentation with the testcase attached caused me to realize that Firefox is only hanging for approximately 45 seconds, after which control is returned to the user. Attempts to reduce the size of the HTML file have resulted in the "hang time" being drastically reduced. Then I tried increasing the size of the file to see what the results would be. My unscientific method yielded the following: 548 kb: 120 seconds 472 kb: 80 seconds 328 kb: 45 seconds 180 kb: 12 seconds 132 kb: 4 seconds It looks like an increase of less than 50% in file size causes the "hang time" to double. In the case of the largest two, the file size was increased only by 20%, and the hang time went up 50%. I'd say it might be something with the layout engine, but the hang doesn't occur until several seconds after the page has already been drawn, though.

Comment on attachment 352694 [details] Apple crash report + process sampling This hang was on gmail

99% certain

Bug 468736 is "PSM nsPSMBackgroundThread::requestExit is racy and not threadsafe". The sample I captured doesn't even contain a nsPSMBackgroundThread, so this appears to be a different bug. A website that I visit fairly frequently will cause this hang every single time, and therefore, I can't upgrade to FF 3.5 until this is addressed. In the testcase, it may only hang the browser for a minute or so, but in actual browsing, it can end up hanging for hours. Nominated for blocking 3.6.

your local testcases has: <script language="javascript" src="0-1_files/javascript.js"></script> we don't have 0-1_files/javascript.js If you want to attach a testcase, you need to 1. attach files that are needed by other files, in this case 0-1_files/javascript.js 2. change your local testcase to reference the attachments (try using full urls) 3. verify that your problem still occurs 4. attach the file that needs the attachment from 1. note that your sample shows that you might be using java, beyond the fact that there's xpconnect and javascript and some minimal locking, i can't see anything w/o symbols and the builds we ship don't include symbols.

That the line referencing the javascript remained in the testcase was an oversight. Removing that line from the testcase makes no difference. The page renders fine, and about 5 seconds after it's been rendered, the browser hangs for about 30 seconds. Please trust me when I say that I'm confident that this has nothing to do with JS. I had a whole bunch of tabs open when I captured that sample, so I'll re-do it, this time while running the testcase (minus the <script> line), maybe it will be more clear.

So, I created a new profile, removed the <script>blah blah blah</script> line from the testcase, and made sure no tabs or windows were open, opened the testcase from my desktop, then captured the hang. I should emphasize that the hang is ONLY occurring when the testcase is loaded LOCALLY, from my desktop. The hang does not occur when the testcase is loaded from mozilla.org. However, the hang DOES happen every single time I visit the website in question.

There is no reason for this to be UNCONFIRMED. See Comment #4.

Confirming. This is a loop hang, we eat 100% CPU when the attachment 351684 [details] loads in today m-c debug build. C++ stack: > js3250.dll!js_Interpret(JSContext * cx=0x00dfe648) Line 4436 + 0x16e bytes C++ js3250.dll!js_Invoke(JSContext * cx=0x00dfe648, unsigned int argc=1, int * vp=0x0860e42c, unsigned int flags=0) Line 1394 + 0x9 bytes C++ js3250.dll!js_fun_call(JSContext * cx=0x00dfe648, unsigned int argc=1, int * vp=0x0860e3f4) Line 1985 + 0x13 bytes C++ js3250.dll!js_Interpret(JSContext * cx=0x00dfe648) Line 5147 + 0x17 bytes C++ js3250.dll!js_Invoke(JSContext * cx=0x00dfe648, unsigned int argc=3, int * vp=0x034303a8, unsigned int flags=0) Line 1394 + 0x9 bytes C++ xpc3250.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * wrapper=0x06a61008, unsigned short methodIndex=3, const XPTMethodDescriptor * info=0x00da28b0, nsXPTCMiniVariant * nativeParams=0x0012f6c4) Line 1652 + 0x1b bytes C++ xpc3250.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex=3, const XPTMethodDescriptor * info=0x00da28b0, nsXPTCMiniVariant * params=0x0012f6c4) Line 562 C++ xpcom_core.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x060613f0, unsigned int methodIndex=3, unsigned int * args=0x0012f784, unsigned int * stackBytesToPop=0x0012f774) Line 114 + 0x21 bytes C++ xpcom_core.dll!SharedStub() Line 142 C++ xpcom_core.dll!nsTimerImpl::Fire() Line 443 C++ xpcom_core.dll!nsTimerImpl::Fire() Line 443 C++ xpcom_core.dll!nsTimerEvent::Run() Line 521 C++ xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012f840) Line 516 + 0x19 bytes C++ xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00d23aa0, int mayWait=1) Line 230 + 0x16 bytes C++ gkwidget.dll!nsBaseAppShell::Run() Line 170 + 0xc bytes C++ tkitcmps.dll!nsAppStartup::Run() Line 193 + 0x1c bytes C++ xul.dll!XRE_main(int argc=3, char * * argv=0x00d1b340, const nsXREAppData * aAppData=0x00d1ba88) Line 3340 + 0x25 bytes C++ firefox.exe!NS_internal_main(int argc=3, char * * argv=0x00d1b340) Line 156 + 0x12 bytes C++ firefox.exe!wmain(int argc=3, wchar_t * * argv=0x00d11040) Line 110 + 0xd bytes C++ firefox.exe!__tmainCRTStartup() Line 594 + 0x19 bytes C firefox.exe!wmainCRTStartup() Line 414 C kernel32.dll!7c817077() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] js3250.dll!nanojit::live(avmplus::GC * gc=0x0069006c, nanojit::LirBuffer * lirbuf=0x004b0063) Line 1555 + 0x13 bytes C++ JS stack: 0 sss_xph_generate(aNode = [object XPCNativeWrapper [object HTMLInputElement @ 0 xf03acd0 (native @ 0x6f756c8)]]) ["file:///D:/mozilla/mozilla-central/_obj-brows er-debug/dist/bin/components/nsSessionStore.js":2830] nName = "271830" count = 0 tag = "xhtml:input" prefix = "xhtml" this = [object Object] 1 sss_collectFormDataForFrame(aDocument = [object XPCNativeWrapper [object HTMLD ocument @ 0x6c26170 (native @ 0x6c1c8c8)]]) ["file:///D:/mozilla/mozilla-central /_obj-browser-debug/dist/bin/components/nsSessionStore.js":1479] data = [object Object] node = [object XPCNativeWrapper [object HTMLInputElement @ 0xf03acd0 (native @ 0x6f756c8)]] formNodes = [object XPCNativeWrapper [object XPathResult @ 0x86170f8 (native @ 0x8613a80)]] this = [object Object] 2 sss_updateTextAndScrollDataForFrame(aFullData = undefined, aUpdateFormData = t rue, aData = [object Object], aContent = [object XPCNativeWrapper [object Window @ 0x4caa6a0 (native @ 0x4d775d0)]], aWindow = [object ChromeWindow @ 0x3c49798 (native @ 0x3c51188)]) ["file:///D:/mozilla/mozilla-central/_obj-browser-debug/d ist/bin/components/nsSessionStore.js":1413] scrollY = undefined scrollX = undefined domWindowUtils = undefined isHTTPS = false i = 0 this = [object Object] 3 sss_updateTextAndScrollDataForTab(aFullData = undefined, aTabData = [object Ob ject], aBrowser = [object XULElement @ 0x4dcc4b0 (native @ 0x4d2c718)], aWindow = [object ChromeWindow @ 0x3c49798 (native @ 0x3c51188)]) ["file:///D:/mozilla/m ozilla-central/_obj-browser-debug/dist/bin/components/nsSessionStore.js":1378] selectedPageStyle = "" tabIndex = 2 this = [object Object] 4 sss_updateTextAndScrollData(aWindow = [object ChromeWindow @ 0x3c49798 (native @ 0x3c51188)]) ["file:///D:/mozilla/mozilla-central/_obj-browser-debug/dist/bin /components/nsSessionStore.js":1344] tabData = [object Object] i = 0 browsers = [object XULElement @ 0x4dcc4b0 (native @ 0x4d2c718)] this = [object Object] 5 sss_collectWindowData(aWindow = [object ChromeWindow @ 0x3c49798 (native @ 0x3 c51188)]) ["file:///D:/mozilla/mozilla-central/_obj-browser-debug/dist/bin/compo nents/nsSessionStore.js":1692] this = [object Object] 6 anonymous(aWindow = [object ChromeWindow @ 0x3c49798 (native @ 0x3c51188)]) [" file:///D:/mozilla/mozilla-central/_obj-browser-debug/dist/bin/components/nsSess ionStore.js":1614] this = [object Object] 7 sss_forEachBrowserWindow(aFunc = [function], [object Object]) ["file:///D:/moz illa/mozilla-central/_obj-browser-debug/dist/bin/components/nsSessionStore.js":2 487] window = [object ChromeWindow @ 0x3c49798 (native @ 0x3c51188)] windowsEnum = [xpconnect wrapped nsISimpleEnumerator @ 0x860e580 (native @ 0 x860e4b8)] windowMediator = [xpconnect wrapped nsIWindowMediator @ 0x50ffad0 (native @ 0x34ecd40)] this = [object Object] 8 sss_getCurrentState(aUpdateAll = undefined) ["file:///D:/mozilla/mozilla-centr al/_obj-browser-debug/dist/bin/components/nsSessionStore.js":1619] lastClosedWindowsCopy = undefined ix = undefined nonPopupCount = undefined windows = undefined total = undefined activeWindow = [object ChromeWindow @ 0x3c49798 (native @ 0x3c51188)] this = [object Object] 9 sss_saveState(aUpdateAll = undefined) ["file:///D:/mozilla/mozilla-central/_ob j-browser-debug/dist/bin/components/nsSessionStore.js":2422] oState = undefined this = [object Object] 10 sss_observe(aData = null, aTopic = "timer-callback", aSubject = [xpconnect wr apped nsITimer @ 0x3b052f8 (native @ 0x61c5868)]) ["file:///D:/mozilla/mozilla-c entral/_obj-browser-debug/dist/bin/components/nsSessionStore.js":454] oState = undefined win = undefined _this = [object Object] this = [object Object]

It's not a JS engine bug if the ilooping script is chrome and if (as I seem to recall) in chrome the iloop watchdog thread / operation callback is turned off. Is the loop starting at http://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/src/nsSessionStore.js#2834 the one that's stuck? Does that mean a cycle in the DOM was created via previousSibling? /be

this looks like a dupe of bug 477564

Even though I reported it 2 months before bug 477564... Agreed.