282673 - 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]

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[kakurady]

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 1

[kakurady]

Attachment: compressed Dr.Watson's log of the 2nd crash(1st time used to log the err), compressed as file too big(round 1M)

Comment 2

[Richard Stagg]

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

[0jacobnk.mozbug]

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

[0jacobnk.mozbug]

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.)

Comment 5

[Jay Patel [:jay]]

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.

Comment 6

[Andrew Schultz]

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

[Jay Patel [:jay]]

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

[0jacobnk.mozbug]

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

[0jacobnk.mozbug]

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

[0jacobnk.mozbug]

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

[Jay Patel [:jay]]

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).

Comment 12

[0jacobnk.mozbug]

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.