I just upgraded my nightly-channel browser (linux-x64, ubuntu), and I noticed it starts consuming 100% of cpu (on one of my CPUs) forever after about a minute. (I also eventually figured out that my "upgrade" was somehow just to the 2011-10-17 build--guess it had been a while. When I upgraded again to 2011-11-03, I don't see the hang. So this is probably all moot?) After downloading symbols, I managed to get a stack trace: #0 0x00007f3c09584faf in GetRootSHEntry (aEntry=<value optimized out>) at /builds/slave/m-cen-lnx64-ntly/build/docshell/base/nsDocShell.cpp:10306 #1 0x00007f3c0958727f in nsDocShell::SetHistoryEntry (this=0x7f3bdb5ea800, aPtr=0x7f3bdb5eaa88, aEntry=0x7f3bdbd7c900) at /builds/slave/m-cen-lnx64-ntly/build/docshell/base/nsDocShell.cpp:10323 #2 0x00007f3c0958df0f in nsDocShell::InternalLoad (this=<value optimized out>, aURI=0x7f3bdbe336e0, aReferrer=0x7f3bdbe337c0, aOwner=<value optimized out>, aFlags=<value optimized out>, aWindowTarget=<value optimized out>, aTypeHint=0x7f3c0a911380 "", aPostData=0x0, aHeadersData=0x0, aLoadType=<value optimized out>, aSHEntry=0x7f3bdbd7c900, aFirstParty=true, aDocShell=0x0, aRequest=0x0) at /builds/slave/m-cen-lnx64-ntly/build/docshell/base/nsDocShell.cpp:8560 #3 0x00007f3c0959afe0 in nsDocShell::LoadHistoryEntry (this=0x7f3bdb5ea800, aEntry=<value optimized out>, aLoadType=<value optimized out>) at /builds/slave/m-cen-lnx64-ntly/build/docshell/base/nsDocShell.cpp:10052 #4 0x00007f3c0958fbd5 in nsDocShell::LoadURI (this=0x7f3bdb5ea800, aURI=0x7f3bdbe336e0, aLoadInfo=<value optimized out>, aLoadFlags=<value optimized out>, aFirstParty=false) at /builds/slave/m-cen-lnx64-ntly/build/docshell/base/nsDocShell.cpp:1366 #5 0x00007f3c095be796 in nsSHistory::InitiateLoad (this=<value optimized out>, aFrameEntry=<value optimized out>, aFrameDS=0x7f3bdb5ea900, aLoadType=<value optimized out>) at /builds/slave/m-cen-lnx64-ntly/build/docshell/shistory/src/nsSHistory.cpp:1760 #6 0x00007f3c095bf05d in nsSHistory::LoadEntry (this=0x7f3bd7a60160, aIndex=1, aLoadType=2, aHistCmd=3) at /builds/slave/m-cen-lnx64-ntly/build/docshell/shistory/src/nsSHistory.cpp:1627 #7 0x00007f3c095bdc81 in nsSHistory::ReloadCurrentEntry (this=0x7f3bd7a60160) at /builds/slave/m-cen-lnx64-ntly/build/docshell/shistory/src/nsSHistory.cpp:913 #8 0x00007f3c098a53ea in NS_InvokeByIndex_P (that=<value optimized out>, methodIndex=<value optimized out>, paramCount=<value optimized out>, params=<value optimized out>) at ../../../../../../../xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:195 #9 0x00007f3c094f55e8 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) () from /home/jj/bin/mozilla/firefox-nightly/libxul.so #10 0x00007f3c094fc7b4 in XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) () from /home/jj/bin/mozilla/firefox-nightly/libxul.so #11 0x00007f3c09c3ba15 in CallCompiler::generateNativeStub() () from /home/jj/bin/mozilla/firefox-nightly/libxul.so #12 0x00007f3c09c397d3 in js::mjit::ic::NativeCall(js::VMFrame&, js::mjit::ic::CallICInfo*) () from /home/jj/bin/mozilla/firefox-nightly/libxul.so This is my work profile that's barfing (lots of tabs, stored passwords, etc). I'm happy to provide it privately to someone. I don't see the problem on a fresh build. I did try turning off add-ons and I still hang. I don't see the problem on a fresh profile. Nor do I seem to be able to see it on a fresh build of Mozilla inbound. So maybe this has already been fixed, and I've wasted lots of time :0 This is with nightly 2011-10-17 (That's when I realized I had a stale upgrade. Everything works fine with nightly 2011-11-03. Sigh).

could be the session restore loop thing?

Yes, I think so, especially since it works with the same sessionrestore.js on the newer nightly.