compressed Dr.Watson's log of the 2nd crash(1st time used to log the err), compressed as file too big(round 1M)
81.29 KB, application/octet-stream
Created attachment 174653 [details] compressed Dr.Watson's log of the 2nd crash(1st time used to log the err), compressed as file too big(round 1M)
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.
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.
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.)
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
Keywords: stackwanted → crash, topcrash
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]
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?
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+
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.
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.
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 :/ ).
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
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
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.
Crash Signature: [@ nsCheapStringBufferUtils::CopyToBuffer]
You need to log in before you can comment on or make changes to this bug.