Closed
Bug 506428
Opened 15 years ago
Closed 13 years ago
download.cnet.com - with cookies disabled, uses one core to 100% (slow/freeze/hang) and the window closes after some time
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: reneb, Unassigned)
References
()
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) 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%
Comment 1•15 years ago
|
||
How old is your computer? :)
Comment 2•15 years ago
|
||
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
Comment 5•15 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1pre) 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:1.9.1.1pre) 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
Comment 7•15 years ago
|
||
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
Comment 8•15 years ago
|
||
This won't be a cookie bug... my guess is some bad javascript that's creating an infinite loop or somesuch, as a result of not being able to set cookies. Though it must be a bit more complex than that, given it ends with a crash rather than a slow script dialog.
Component: Networking: Cookies → General
Product: Core → Firefox
QA Contact: networking.cookies → general
Version: 1.9.1 Branch → 3.5 Branch
Comment 9•15 years ago
|
||
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.
Keywords: testcase-wanted
Comment 11•15 years ago
|
||
I can confirm this with cookies disabled just for cnet.com. Behavior of FF is not normal, even when the script is bad. Lucas
Updated•15 years ago
|
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
Comment 12•15 years ago
|
||
When I set: javascript.options.jit.content to false, it still reproduces. So, it is not TM related.
Comment 13•15 years ago
|
||
Problem still there with 3.5.2.
Comment 14•15 years ago
|
||
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
Comment 15•15 years ago
|
||
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.
Comment 16•15 years ago
|
||
By the way, this bug also results in run-away memory consumption, if the hang is left to run its course.
Comment 17•15 years ago
|
||
Sorry for the bug spam. I should have mentioned that I'm reproducing this on the current trunk builds.
Comment 18•15 years ago
|
||
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.
Comment 19•15 years ago
|
||
Maybe it gets into a kind of event fire loop.
Comment 21•15 years ago
|
||
I've attached the core dump taken by Visual Studio when Firefox was running in the Safe mode
Comment 22•15 years ago
|
||
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]
Comment 23•15 years ago
|
||
This bugs affects seamonkey as well - reproducible in 1.18 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090825 SeaMonkey/1.1.18) and 2.0b2 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090903 SeaMonkey/2.0b2)
Comment 24•15 years ago
|
||
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.
Comment 25•15 years ago
|
||
/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
Comment 26•15 years ago
|
||
Sounds like we produced a mangled dump. Not much we can do about that (until we get to a multi-process setup).
Comment 27•13 years ago
|
||
Reporter:; Is this still a problem with FF4 ?
Reporter | ||
Comment 28•13 years ago
|
||
Works for me with FF4 :-)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Updated•9 years ago
|
Keywords: testcase-wanted
You need to log in
before you can comment on or make changes to this bug.
Description
•