Closed Bug 401814 Opened 17 years ago Closed 15 years ago

Insufficient check of "Out of memory" at re-parsing document after document.write() causes crash [@ nsScannerString::AppendBuffer]

Categories

(Core :: DOM: HTML Parser, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 430574

People

(Reporter: masa141421356, Unassigned)

References

()

Details

(Keywords: crash)

Crash Data

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8 This bug is diveded from Bug 345161. When OS Low memory , Insufficient check of "Out of memory" at re-parse of document after document.write() causes crash. Reproducible: Always Steps to Reproduce: 1.Make your OS to "Low memory" 2.Run JavaScript code that outputs huge text using document.write() Actual Results: Windows displays low-memory caution dialog: > Your system is low on virtual memory. To ensure that Windows runs properly, > increase the size of your virtual memory paging file. For more information, > see Help. After it, Firefox will crash. Expected Results: Firefox should not crash. I think document.write() should throw JavaScript's exception. I think this bug causes DoS but not cases code execution because memory usage of OS depends on other proccess's memory usage.. Crash log at Fx2.0.0.3 on Windows is here. But sometimes crash-address is different (I think it depends on free memory size). nsScannerString::AppendBuffer [mozilla/parser/htmlparser/src/nsScannerString.cpp, line 355] nsScanner::Append [mozilla/parser/htmlparser/src/nsScanner.cpp, line 336] nsHTMLDocument::WriteCommon [mozilla/content/html/document/src/nsHTMLDocument.cpp, line 2338] nsHTMLDocument::ScriptWriteCommon [mozilla/content/html/document/src/nsHTMLDocument.cpp, line 2420] nsHTMLDocument::Write [mozilla/content/html/document/src/nsHTMLDocument.cpp, line 2447] XPCWrappedNative::CallMethod [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169] XPC_WN_CallMethod [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455] And at this crash, EventLog of Windows is witten: Application Popup: firefox.exe - Application Error: Instaruction at "0x0050b9f6" referenced memory at "0x00000000." The memory cannot be written.
Blocks: 345161
Keywords: crash
Version: unspecified → Trunk
Testcase exists on Bug 345161. This bug is reproducable at Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007103004 Minefield/3.0a9pre.
Component: General → HTML: Parser
QA Contact: general → parser
Summary: Insufficient check of "Out of memory" at re-parsing document after document.write() causes crash → Insufficient check of "Out of memory" at re-parsing document after document.write() causes crash [@ nsScannerString::AppendBuffer]
My reason to think "Bug may exist in re-parse" is here. ----------------- Testcase of Bug 345161 contains special crafted infinite loop. (1)Output LONGTEXT by document.write() in <SCRIPT> element. (2)Re-parse fo document is executed caused by (1). (see http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.4) (3)Set LONGTEXT to be longer than before. (4)Go to (1) If infinite loop does not contains (2), Firefox does NOT crash. I think it means crash is caused by some bug in (2).
sorry, i've already highlighted the bug. we don't really need more analysis, we just need someone to fix it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 441670
So it looks like on trunk this got fixed by bug 430574. We should probably just backport that.
Depends on: 430574
(In reply to comment #4) > So it looks like on trunk this got fixed by bug 430574. We should probably > just backport that. Ha, yes. After making the obvious change to CVS HEAD, I looked at trunk and found nearly identical code there. Kind of creepy. I'll take care of the backport.
(In reply to comment #5) > (In reply to comment #4) > > So it looks like on trunk this got fixed by bug 430574. We should probably > > just backport that. > > Ha, yes. After making the obvious change to CVS HEAD, I looked at trunk and > found nearly identical code there. Kind of creepy. I'll take care of the > backport. Or not. You're quick, bz :) https://bugzilla.mozilla.org/show_bug.cgi?id=430574#c17 https://bugzilla.mozilla.org/show_bug.cgi?id=441670#c10
At my debubbuild, Crash still reproduced with 3rd testcase of bug 345161. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081102 Minefield/3.1b2pre from http://hg.mozilla.org/mozilla-central/rev/5b609dfce6c9+ Console shows: WARNING: NS_ENSURE_TRUE(!mTooDeepWriteRecursion) failed: file f:/mozbuild/src/content/html/document/src/nsHTMLDocument.cpp, line 2148 WARNING: NS_ENSURE_TRUE(!mTooDeepWriteRecursion) failed: file f:/mozbuild/src/content/html/document/src/nsHTMLDocument.cpp, line 2148 WARNING: NS_ENSURE_TRUE(!mTooDeepWriteRecursion) failed: file f:/mozbuild/src/content/html/document/src/nsHTMLDocument.cpp, line 2148 ###!!! ASSERTION: You can't |write| into an |nsWritingIterator| with no space!: 'size_forward() > 0', file f:\mozbuild\src\fx-debug\dist\include\string\nsStringIterator.h, line 324 Warning of nsHTMLDocument.cpp, line 2148 was many times repeated (scroll buffer is filled by it).
Bug 430574 fixed this, right?
(In reply to comment #8) > Bug 430574 fixed this, right? Yes, it just needed to be back-ported to CVS HEAD.
(In reply to comment #8) > Bug 430574 fixed this, right? I think yes. Crash at comment #7 seems to be problem around code enabled for debugging. And, current trunk does not crash (but still hangs) with 3rd testcase of bug 345161.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Crash Signature: [@ nsScannerString::AppendBuffer]
You need to log in before you can comment on or make changes to this bug.