User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20090715 Firefox/3.5.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20090715 Firefox/3.5.1 I tried several of the download pages on download.cnet.com and they all use a lot of processing power and then the window simply shuts down. Did not happen with Firefox 3.1. I tried it in Save mode with all add-ons disabled, same effect Reproducible: Always Steps to Reproduce: 1. Go to http://download.cnet.com/Process-Explorer/3000-2094_4-10223605.html?dl-blog&tag=mncol;txt 2. 3. Actual Results: Firefox 3.5.1 closes window after some time using one processor core to 100%
How old is your computer? :)
Maybe this helps: http://support.mozilla.com/en-US/kb/Firefox+crashes+when+trying+to+download+a+file ?
Version: unspecified → 3.5 Branch
(In reply to comment #1) > How old is your computer? :) It's a XFX 750i with a Q9400@2.66GHz, 4GB RAM (1GHz), no overclocking and more than enough room on the 250 GB RAID Good enough? :-)
(In reply to comment #2) > Maybe this helps: > http://support.mozilla.com/en-US/kb/Firefox+crashes+when+trying+to+download+a+file > ? I do NOT try to download the file. The page opens, is busy and then Firefox just closes dwon. I do NOT click on anything
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:18.104.22.168pre) Gecko/20090720 Shiretoko/3.5.1pre No problem here with the site. Can you try the following trouble-shooting options: - Firefox's safe-mode to exclude extension/theme problems - a new profile - a reinstall in a new empty folder http://support.mozilla.com/en-US/kb/Safe+Mode http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile
(In reply to comment #5) > Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:22.214.171.124pre) Gecko/20090720 > Shiretoko/3.5.1pre > > No problem here with the site. Can you try the following trouble-shooting > options: > > - Firefox's safe-mode to exclude extension/theme problems > - a new profile I made a new profile, installed all my add-ons and it worked fine. But then I found the reason for the problem: I do NOT allow cookies in my default profile. As soon as I allowed it for download.cnet.com it worked fine. So the problem is obviously the function on the cnet website. Still I find the behaviour of Firefox kind of buggy. Thanks for the help. > - a reinstall in a new empty folder > > http://support.mozilla.com/en-US/kb/Safe+Mode > http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile
I just checked and indeed, I see the hang. But I tried also Opera and Google Chrome and they hang too, although not as serious. Not sure why Firefox has no choice than too hang.
Component: General → Networking: Cookies
Product: Firefox → Core
QA Contact: general → networking.cookies
Version: 3.5 Branch → 1.9.1 Branch
Component: Networking: Cookies → General
Product: Core → Firefox
QA Contact: networking.cookies → general
Version: 1.9.1 Branch → 3.5 Branch
I can reproduce this with cookies disabled. Memory usage slowly went up to about 500 MB and then the window closed. No crash reporter. A reduced testcase would be nice here.
I can confirm this with cookies disabled just for cnet.com. Behavior of FF is not normal, even when the script is bad. Lucas
Summary: Pages on download.cnet.com use one core to 100% and the windows closes after some time → download.cnet.com - with cookies disabled, uses one core to 100% (slow/freeze/hang) and the window closes after some time
Problem still there with 3.5.2.
I copied the page to my local disk. I started Apache. I added the <base href="..."> tag, disabled all cookies and loaded the page via 127.0.0.1. It doesn't reproduce that way. There is no XHR. I see that both with original site and copy. So, what could be the difference? A real domain name???? Anyone any ideas? This is spooky. This way I can't reduce it. Lucas
Created attachment 393154 [details] Website files I tried to see where the hang was occurring but couldn't. Anyways, the debugger was complaining about line 114 of the CookieXfer.html file (contained in the attached) returning no value, just before the hang.
By the way, this bug also results in run-away memory consumption, if the hang is left to run its course.
Sorry for the bug spam. I should have mentioned that I'm reproducing this on the current trunk builds.
Some notes. The CookieXfer.htm is loaded by <iframe> if you have cookies disabled. If cookie is enabled, it will not appear on the site (the server probably reacts on the http header info). The CookieXfer.htm is loaded 4 times in the attachment of #15. Probably, only 1 was intended. The path of oreao.js in the CookieXfer.htm is not correct (bug in saving). Remove the first part of the path. But that doesn't help to reproduce it locally. There are still some things that are necessary to reproduce it locally. Don't know what the CookieXfer.htm file is doing. Probably to do an alternative when cookies are disabled, but I don't know what. Probably some paths have to be corrected, to get reproduced locally. But then I need to know what it is doing. Maybe a bisect could help (if it doesn't reproduce with older versions). Then we have some clue where to look.
Maybe it gets into a kind of event fire loop.
Created attachment 394934 [details] Crash dump (taken with Visual Studio) and WinDbg analysis (of that dump) I've attached the core dump taken by Visual Studio when Firefox was running in the Safe mode
You crashed because windows ran out of memory. This happens. 00123f6c 7815d2ab kernel32!RaiseException+0x53 00123fa4 78165c93 mozcrt19!_CxxThrowException(void * pExceptionObject = 0x00123fb4, struct _s__ThrowInfo * pThrowInfo = 0x781cba44)+0x46 [f:\sp\vctools\crt_bld\self_x86\crt\prebuild\eh\throw.cpp @ 161] 00123fbc 10029782 mozcrt19!operator new(unsigned int size = <Memory access error>)+0x73 [e:\builds\moz2_slave\win32_build\build\obj-firefox\memory\jemalloc\src\new.cpp @ 61] 00124024 100cbf25 xul!nsNullPrincipal::Init(void)+0xf2 [e:\builds\moz2_slave\win32_build\build\caps\src\nsnullprincipal.cpp @ 127] 00124038 10044033 xul!nsNullPrincipalConstructor(class nsISupports * aOuter = 0x616c6c69, struct nsID * aIID = 0x67726f2e, void ** aResult = 0x6c756e2f)+0x65 [e:\builds\moz2_slave\win32_build\build\caps\src\nssecuritymanagerfactory.cpp @ 347] 00124048 100308ad xul!nsGenericFactory::CreateInstance(class nsISupports * aOuter = 0x67726f2e, struct nsID * aIID = 0x6c756e2f, void ** aResult = 0x6972706c)+0x23 [e:\builds\moz2_slave\win32_build\build\obj-firefox\xpcom\build\nsgenericfactory.cpp @ 84] 00124064 109c92f4 xul!nsComponentManagerImpl::CreateInstanceByContractID(char * aContractID = 0x67726f2e "--- memory read error at address 0x67726f2e ---", class nsISupports * aDelegate = 0x6c756e2f, struct nsID * aIID = 0x6972706c, void ** aResult = 0x7069636e)+0xbd [e:\builds\moz2_slave\win32_build\build\xpcom\components\nscomponentmanager.cpp @ 1687] 00124090 100bed02 xul!nsTArray_base::sEmptyHdr+0x8 001240b0 101603a7 xul!nsDocument::Init(void)+0x1d2 [e:\builds\moz2_slave\win32_build\build\content\base\src\nsdocument.cpp @ 1865] 001240b8 10188a16 xul!nsHTMLDocument::Init(void)+0x8 [e:\builds\moz2_slave\win32_build\build\content\html\document\src\nshtmldocument.cpp @ 275] 001240c0 10188a4a xul!NS_NewHTMLDocument(class nsIDocument ** aInstancePtrResult = 0x89800000)+0x2f [e:\builds\moz2_slave\win32_build\build\content\html\document\src\nshtmldocument.cpp @ 215] 001240d4 10044033 xul!CreateHTMLDocument(class nsISupports * aOuter = 0xc033108c, struct nsID * aIID = 0x89e806c7, void ** aResult = 0x86c7108c)+0x1e [e:\builds\moz2_slave\win32_build\build\layout\build\nslayoutmodule.cpp @ 481] 001240e4 100440f2 xul!nsGenericFactory::CreateInstance(class nsISupports * aOuter = <Memory access error>, struct nsID * aIID = <Memory access error>, void ** aResult = <Memory access error>)+0x23 [e:\builds\moz2_slave\win32_build\build\obj-firefox\xpcom\build\nsgenericfactory.cpp @ 84] 00124108 1001d626 xul!nsComponentManagerImpl::CreateInstance(struct nsID * aClass = <Memory access error>, class nsISupports * aDelegate = <Memory access error>, struct nsID * aIID = <Memory access error>, void ** aResult = <Memory access error>)+0xb2 [e:\builds\moz2_slave\win32_build\build\xpcom\components\nscomponentmanager.cpp @ 1601] 0012412c 10059937 xul!nsCreateInstanceByCID::operator()(struct nsID * aIID = 0x781d8ba8, void ** aInstancePtr = 0x0b11045c)+0x26 [e:\builds\moz2_slave\win32_build\build\obj-firefox\xpcom\build\nscomponentmanagerutils.cpp @ 199] 0012413c 101363e8 xul!nsCOMPtr_base::assign_from_helper(class nsCOMPtr_helper * helper = 0x781d8ba8, struct nsID * iid = 0x0b11045c)+0x17 [e:\builds\moz2_slave\win32_build\build\obj-firefox\xpcom\build\nscomptr.cpp @ 150] 00124170 10160806 xul!nsContentDLF::CreateDocument(char * aCommand = 0x108c2640 "view", class nsIChannel * aChannel = 0x1089b90c, class nsILoadGroup * aLoadGroup = 0x107bdc78, class nsISupports * aContainer = 0x00000000, struct nsID * aDocumentCID = 0x0012416c, class nsIStreamListener ** aDocListener = 0x0b1b68a0, class nsIContentViewer ** aDocViewer = 0x00000000)+0x66 [e:\builds\moz2_slave\win32_build\build\layout\build\nscontentdlf.cpp @ 429] 00000000 00000000 xul!nsContentDLF::CreateInstance(char * aCommand = <Memory access error>, class nsIChannel * aChannel = <Memory access error>, class nsILoadGroup * aLoadGroup = <Memory access error>, char * aContentType = <Memory access error>, class nsISupports * aContainer = <Memory access error>, class nsISupports * aExtraInfo = <Memory access error>, class nsIStreamListener ** aDocListener = <Memory access error>, class nsIContentViewer ** aDocViewer = <Memory access error>)+0x180 [e:\builds\moz2_slave\win32_build\build\layout\build\nscontentdlf.cpp @ 236]
This bugs affects seamonkey as well - reproducible in 1.18 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20090825 SeaMonkey/1.1.18) and 2.0b2 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/20090903 SeaMonkey/2.0b2)
This is probably just spam cause there doesn't look to be much information, but not sure. Might help. Anyhow my crash report: http://crash-stats.mozilla.com/report/index/bp-4a8c96c0-04b7-4b1c-8dc8-b40272091031 XP SP3, all plugins disabled, no extensions, 2 GB physical Mem, SeaMonkey 2.
/home/processor/stackwalk/bin/stackwalk.sh returned no header lines for reportid: 68970976; No thread was identified as the cause of the crash; No signature could be created because we do not know which thread crashed; /home/processor/stackwalk/bin/stackwalk.sh returned no frame lines for reportid: 68970976; /home/processor/stackwalk/bin/stackwalk.sh failed with return code 1 when processing dump 4a8c96c0-04b7-4b1c-8dc8-b40272091031
Sounds like we produced a mangled dump. Not much we can do about that (until we get to a multi-process setup).
Reporter:; Is this still a problem with FF4 ?
Works for me with FF4 :-)
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.