Closed
Bug 282673
Opened 19 years ago
Closed 19 years ago
When popping out a simple dialog Firefox allocates tons of memory and sometimes make an access violation when no memory is avalible - FF10x M17x [@ nsCheapStringBufferUtils::CopyToBuffer]
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: kakurady, Assigned: bugzilla)
Details
(Keywords: crash, topcrash)
Crash Data
Attachments
(1 file)
81.29 KB,
application/octet-stream
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Win98; zh-CN; rv:1.7.5) Gecko/20041124 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Win98; zh-CN; rv:1.7.5) Gecko/20041124 Firefox/1.0 I have been using Firefox for a while and I liked it very much. Not long ago Firefox starts to stop responding for a while when browsing but I paid no attention. Then it starts read HDD so suddenly when browsing and hangs at the same time. But this day I clicked a link whick triggered an OnClick event which runs a line of javascript code which returns with the result of a comfirm(). (Forgive me of my verbosity. ) Then after a long long wait, a box appeared telling me Firefox has made an access violation (later I found out,'twas caused by doing mov dword ptr[eax],esi when eax = 00000000). At this point I reproduced this bug with Dr.Watson running(for 3 times), and found out if given sufficient memory and swap file(virtual memory), it will still pop out the dialog. I also accidentaly found out this happens too when Firefox prompts you if to save a password or not. However these tests have made my computer run out of virtual memory(2 MMORPGs installed on a 7.29G partition), so I rebooted and entered DOS to delete the swap file. I also copied firefox to another directory (as I suspected this problem has to do with XPCOM.dll so I want to get it's CRC hash in order to know if the file is corrupted). After doing these steps I cannot reproduce the problem any more...(If not I would have to report this as a BLOCKER, as this blocks me from entering password to bugzilla.) And just as I'm filling this report the OS prompts me that Firefox crushes *again*... but it is still responding and functional and not closed, and the problem was found in MFC42.dll. Maybe that's corrupted file(as I got numerous errors with this file)? Reproducible: Sometimes Steps to Reproduce: 1.Execute a script with a confirm function or try to make the dialog asking if to save password appear. Actual Results: Firefox allocates memory at an amazing speed then pops up the dialog; or in the end runs out of memory and try to access memory with an uninit'ed pointer. Expected Results: Pop up the dialog without too much delay. Or at least say that the pointer is invaild(but how do you know that...)
Comment 2•19 years ago
|
||
I concur. (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0) In some situations, invoking a confirm dialogue, or a 'save password' dialogue will result in the browser becoming practically unresponsive and claiming more and more virtual memory. It can be killed using Task Manager before it crashes with an access violation. The bug is frustratingly intermittent and hard to reproduce.
Comment 3•19 years ago
|
||
I am also running into this a lot with Firefox 1.0.2 on Windows 98. (Mozilla/5.0 (Windows; U; Win98; en-GB; rv:1.7.6) Gecko/20050321 Firefox/1.0.2) Any message box seems to pretty reliably cause Firefox to use up swap space until I run out of disc space (upon which Win98 invokes "disk cleanup"). Sometimes Firefox crashes at this point. Typical messages boxes which cause this include: - the "close multiple tabs" confirmation - password prompt for HTTP authentication - "document contains no data" or "host not found" I don't recall ever running into this with FF 1.0, or 1.0.1. However, it seems to have been happening to me pretty much every day since I installed 1.0.2. If I can be of assistance in tracking this down, let me know.
Comment 4•19 years ago
|
||
I got one of these crashes today. I submitted a crash report via the talkback thingy; it's tagged with this PR #. (I have also submitted crash reports previously due to the same problem.)
Keywords: stackwanted
Comment 5•19 years ago
|
||
Found the crash: Incident ID: 4940412 Stack Signature nsCheapStringBufferUtils::CopyToBuffer b02671fa Product ID Firefox10 Build ID 2005032111 Trigger Time 2005-04-08 09:34:12.0 Platform Win32 Operating System Windows 98 4.10 build 67766446 Module FIREFOX.EXE + (001f7c26) URL visited http://cio.co.nz/cio.nsf/0/ab70aab0de0cba74cc256fd2007ff140?OpenDocument&More=Special%20Feature&Click= User Comments This crash is associated with an instance of PR #282673. Since Last Crash 70260 sec Total Uptime 395244 sec Trigger Reason Access violation Source File, Line No. ../../../dist/include/content\nsHTMLValue.h, line 99 Stack Trace nsCheapStringBufferUtils::CopyToBuffer [../../../dist/include/content/nsHTMLValue.h, line 99] nsAttrValue::ParseStringOrAtom [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/content/base/src/nsAttrValue.cpp, line 735] nsXULPrototypeElement::Deserialize [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp, line 4280] nsXULPrototypeElement::Deserialize [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp, line 4308] nsXULPrototypeDocument::Read [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/content/xul/document/src/nsXULPrototypeDocument.cpp, line 438] nsXULPrototypeCache::GetPrototype [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/content/xul/document/src/nsXULPrototypeCache.cpp, line 280] nsChromeProtocolHandler::NewChannel [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/chrome/src/nsChromeProtocolHandler.cpp, line 677] nsIOService::NewChannelFromURI [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/netwerk/base/src/nsIOService.cpp, line 478] NS_NewChannel [../../../dist/include/necko/nsNetUtil.h, line 166] nsDocShell::DoURILoad [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/docshell/base/nsDocShell.cpp, line 5739] nsDocShell::InternalLoad [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/docshell/base/nsDocShell.cpp, line 5655] nsDocShell::LoadURI [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/docshell/base/nsDocShell.cpp, line 734] nsWindowWatcher::OpenWindowJS [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp, line 775] nsWindowWatcher::OpenWindow [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp, line 458] nsPromptService::DoDialog [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/embedding/components/windowwatcher/src/nsPromptService.cpp, line 638] nsPromptService::Alert [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/embedding/components/windowwatcher/src/nsPromptService.cpp, line 137] nsPrompt::Alert [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/embedding/components/windowwatcher/src/nsPrompt.cpp, line 165] nsDocShell::LoadURI [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/docshell/base/nsDocShell.cpp, line 2746] XPTC_InvokeByIndex [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102] XPCWrappedNative::CallMethod [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2034] XPC_WN_CallMethod [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1287] js_Invoke [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/js/src/jsinterp.c, line 949] js_Interpret [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/js/src/jsinterp.c, line 2993] js_Invoke [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/js/src/jsinterp.c, line 966] js_Interpret [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/js/src/jsinterp.c, line 2993] js_Invoke [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/js/src/jsinterp.c, line 966] js_InternalInvoke [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/js/src/jsinterp.c, line 1043] JS_CallFunctionValue [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/js/src/jsapi.c, line 3698] nsJSContext::CallEventHandler [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1297] nsJSEventListener::HandleEvent [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/dom/src/events/nsJSEventListener.cpp, line 184] nsEventListenerManager::HandleEventSubType [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp, line 1436] nsEventListenerManager::HandleEvent [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp, line 1516] GlobalWindowImpl::HandleDOMEvent [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp, line 927] DocumentViewerImpl::LoadComplete [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/content/base/src/nsDocumentViewer.cpp, line 917] nsDocShell::EndPageLoad [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/docshell/base/nsDocShell.cpp, line 4602] nsWebShell::EndPageLoad [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/docshell/base/nsWebShell.cpp, line 755] nsDocShell::OnStateChange [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/docshell/base/nsDocShell.cpp, line 4536] nsDocLoaderImpl::FireOnStateChange [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/uriloader/base/nsDocLoader.cpp, line 1252] nsDocLoaderImpl::doStopDocumentLoad [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/uriloader/base/nsDocLoader.cpp, line 873] nsDocLoaderImpl::DocLoaderIsEmpty [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/uriloader/base/nsDocLoader.cpp, line 774] nsDocLoaderImpl::OnStopRequest [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/uriloader/base/nsDocLoader.cpp, line 701] nsLoadGroup::RemoveRequest [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/netwerk/base/src/nsLoadGroup.cpp, line 695] nsInputStreamChannel::OnStopRequest [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/netwerk/base/src/nsInputStreamChannel.cpp, line 371] nsInputStreamChannel::`vftable' nsForwardProxyDataSource::AddRef [c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Clobber/mozilla/browser/components/bookmarks/src/nsForwardProxyDataSource.cpp, line 143] 0x8b560c45 Looks like there a quite a few of these crashes on the Aviary (Firefox 1.0.x) and Mozilla 1.7.x branches: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsCheapStringBufferUtils%3A%3ACopyToBuffer&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid I don't see any crashes on the Trunk in those results for this stack signature, but we should find out if it's a problem in recent Trunk nightlies.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: When popping out a simple dialog Firefox allocates tons of memory and sometimes make an access violation when no memory is avalible → When popping out a simple dialog Firefox allocates tons of memory and sometimes make an access violation when no memory is avalible - FF10x M17x [@ nsCheapStringBufferUtils::CopyToBuffer]
Comment 6•19 years ago
|
||
the place this is crashing, nsHTMLValue.h, no longer exists, so the stack signature can't show up in trunk builds (although they still might crash). Can anyone reproduce the crash with a nightly build?
Comment 7•19 years ago
|
||
I've gone through all the urls in the Talkback query I posted earlier and tried to login, navigate the site, and anything else script related I could find and did not notice any excessive memory usage...and did not encounter any crashes with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050408 Firefox/1.0+
Comment 8•19 years ago
|
||
Disregard the web site (cio.co.nz) referenced in my talkback report; it's spurious for this report. Also, I get this crash with non-script-based popups (see above). (I had previously reported a crash with a cio.co.nz URL, on 2005/04/02, which IIRC were unrelated to the circumstances of this PR. Now the talkback thing prompts me with that URL _every time_ FF crashes. I believe I deleted it before submitting. *checks talkback-public.mozilla.org* Nonetheless, every crash report I've submitted since then contains it, which is clearly a bug in the talkback thingum.) For avoidance of doubt, I have to date submitted two talkback reports due to _this_ bug (the message-box one) -- they are 4940412 (quoted above) and the earlier 4865786.
Comment 9•19 years ago
|
||
Also: for me at least, this bug doesn't always cause a crash. Sometimes it will use up all the swap, and then after several minutes' churning, pop up the message box. After that I can carry on using FF as normal, more or less; I think (but haven't checked thoroughly) that its memory consumption becomes relatively sane again once the message box is displayed. I have a feeling that once this has happened once in a session, it doesn't happen again; I've certainly had message boxes pop up without this palaver.
Comment 10•19 years ago
|
||
Since I'll be upgrading to 1.0.3 soon, I'll note in passing that this issue has mysteriously stopped happening for me with 1.0.2 -- I've not seen it for many days, despite getting pop-up message-boxes (and flinching each time :/ ).
Comment 11•19 years ago
|
||
The number of crashes has definitely gone way down since Firefox 1.0.2. I also don't see any crashes in Trunk Talkback data. Marking this worksforme to get it off the radar. If anyone is able to reproduce this with Deer Park or any other Trunk nightly, please reopen (I'm not worried about the Aviary branch because we are probably not going to fix this there).
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Comment 12•19 years ago
|
||
For information: I still occasionally see this with Firefox 1.0.7. (Not the crash so far, just the several-minutes-with-thrashing to bring up a dialog.) I haven't tried 1.5 yet; when I get round to upgrading, I'll let you know.
Updated•13 years ago
|
Crash Signature: [@ nsCheapStringBufferUtils::CopyToBuffer]
You need to log in
before you can comment on or make changes to this bug.
Description
•