Open Bug 569328 Opened 14 years ago Updated 2 years ago

document.write DoS loop crash in [@ operator new(unsigned int) | jArray<unsigned short, int>::jArray<unsigned short, int>(int) ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters]

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: Tobbi, Unassigned)

References

(
URL
)

Details

(Keywords: crash, testcase, Whiteboard: [sg:dos])

Crash Data

Attachments

(1 file)

testcase
550 bytes, text/html
Details
Steps to reproduce: Open the URL above, crash ID: 7f63794a-d1bb-4d68-8656-f8f2c2100601 I'll contact the author of the crashing file and will get him to give me the source of it.
Successfully re-tested on trunk!
Version: unspecified → Trunk
Attached file testcase —
I reduced the HTML file to a simplified testcase.
Keywords: testcase-wanted → testcase
How in the world does a javascript document.write() DoS-loop end up crashing in nsZipArchive::GetData? Do you really get the same crash with the attached testcase as from the original game.html? (have not tested either myself, yet)
(In reply to comment #3) > How in the world does a javascript document.write() DoS-loop end up crashing in > nsZipArchive::GetData? Do you really get the same crash with the attached > testcase as from the original game.html? (have not tested either myself, yet) No, apparently not. The crash that I get with the reduced testcase looks far more weird: http://crash-stats.mozilla.com/report/index/9aaa0b4d-106c-4f7e-9c3c-e84782100601 @ operator new(unsigned int) | TextRunWordCache::MakeTextRun(unsigned char const*, unsigned int, gfxFontGroup*, gfxTextRunFactory::Parameters const*, unsigned int) Could it be that the crash happens at a random memory address?
Another one happens at [@ operator new(unsigned int) | jArray<unsigned short, int>::jArray<unsigned short, int>(int) ] http://crash-stats.mozilla.com/report/index/0483db1d-4df5-42e4-a06c-a32e62100601
Just for the records: I am not the original coder of the crash code. The original author is "Christian Inci". I just modified / minified the source code (removed unnecessary parts).
Bizarre. On Mac trunk it ends up crashing in Mac font code with a null-deref-looking stack: firefox-bin(6956,0xa07bf720) malloc: *** mmap(size=1764749312) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x96034b86 in TASCIIEncoder::Encode () (gdb) bt #0 0x96034b86 in TASCIIEncoder::Encode () #1 0x96033e62 in TGlyphEncoder::EncodeChars () #2 0x9603390e in TTypesetterAttrString::Initialize () #3 0x9603367f in CTLineCreateWithAttributedString () #4 0x04b219b0 in gfxCoreTextShaper::InitTextRun (this=0x1b5c9260, aContext=0x1b5a78b0, aTextRun=0x1abea330, aString=0x752f2008, aRunStart=0, aRunLength=80215758) at /build/m-c/mozilla/gfx/thebes/src/gfxCoreTextShaper.cpp:196 #5 0x04af79aa in gfxFont::InitTextRun (this=0x1b5a7bb0, aContext=0x1b5a78b0, aTextRun=0x1abea330, aString=0x752f2008, aRunStart=0, aRunLength=80215758) at /build/m-c/mozilla/gfx/thebes/src/gfxFont.cpp:1211 #6 0x04b0063b in gfxFontGroup::InitTextRun (this=0x1b5a7b30, aContext=0x1b5a78b0, aTextRun=0x1abea330, aString=0x752f2008, aLength=80215758) at /build/m-c/mozilla/gfx/thebes/src/gfxFont.cpp:1940 #7 0x04b01231 in gfxFontGroup::MakeTextRun (this=0x1b5a7b30, aString=0x2c451008 'x' <repeats 200 times>..., aLength=80215758, aParams=0xbfff61dc, aFlags=17826081) at /build/m-c/mozilla/gfx/thebes/src/gfxFont.cpp:1884 #8 0x04b16eeb in TextRunWordCache::MakeTextRun (this=0xfe60020, aText=0x24800008 'x' <repeats 200 times>..., aLength=80215758, aFontGroup=0x1b5a7b30, aParams=0xbfff7620, aFlags=17826080) at /build/m-c/mozilla/gfx/thebes/src/gfxTextRunWordCache.cpp:807 #9 0x04b17009 in gfxTextRunWordCache::MakeTextRun (aText=0x24800008 'x' <repeats 200 times>..., aLength=80215758, aFontGroup=0x1b5a7b30, aParams=0xbfff7620, aFlags=17826080) at /build/m-c/mozilla/gfx/thebes/src/gfxTextRunWordCache.cpp:1003 #10 0x03a3b783 in MakeTextRun (aText=0x24800008 'x' <repeats 200 times>..., aLength=80215758, aFontGroup=0x1b5a7b30, aParams=0xbfff7620, aFlags=17826080) at /build/m-c/mozilla/layout/generic/nsTextFrameThebes.cpp:470
Summary: crash in [@ nsZipArchive::GetData(nsZipItem*) ] → document.write DoS loop somehow crashed in [@ nsZipArchive::GetData(nsZipItem*) ]
For some reason, on subsequent crashes I'm only crashing in [@ operator new(unsigned int) | jArray<unsigned short, int>::jArray<unsigned short, int>(int) ]. Might be that I accidentally pulled a wrong ID for some reason.
Summary: document.write DoS loop somehow crashed in [@ nsZipArchive::GetData(nsZipItem*) ] → document.write DoS loop crash in [@ operator new(unsigned int) | jArray<unsigned short, int>::jArray<unsigned short, int>(int) ]
Comment 7 and comment 8 are reasonable ways to crash when OOM.
Group: core-security
Whiteboard: [sg:dos]
Since Firefox 6.0 trunk, the new signature for me on Win 7 is: @ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters()
Summary: document.write DoS loop crash in [@ operator new(unsigned int) | jArray<unsigned short, int>::jArray<unsigned short, int>(int) ] → document.write DoS loop crash in [@ operator new(unsigned int) | jArray<unsigned short, int>::jArray<unsigned short, int>(int) ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters()]
Crash Signature: [@ operator new(unsigned int) | jArray<unsigned short, int>::jArray<unsigned short, int>(int) ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters()]
SeaMonkey user reported Bug 665310 with [@ nsHtml5TreeBuilder::flushCharacters() ] Is that a duplicate of this bug?
Crash Signature: [@ operator new(unsigned int) | jArray<unsigned short, int>::jArray<unsigned short, int>(int) ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters()] → [@ operator new(unsigned int) | jArray<unsigned short, int>::jArray<unsigned short, int>(int) ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters()]
Hey guys, I've tried many months to find this bugid. But now I've found it! :-) As far as I can see, it won't crash firefox anymore. (Firefox 6 (ebuild, ver. 28 Aug 2011), Gentoo x86 unstable, Intel Atom N450, 2GB RAM) It would be great, if you can give me any updates. Greetings, Christian
On Windows, the stack trace looks like: Frame Module Signature [Expand] Source 0 mozalloc.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:77 1 mozalloc.dll mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:54 2 xul.dll nsHtml5TreeBuilder::characters parser/html/nsHtml5TreeBuilder.cpp:198 3 xul.dll nsHtml5Tokenizer::stateLoop parser/html/nsHtml5Tokenizer.cpp:3265 4 xul.dll nsHtml5Tokenizer::tokenizeBuffer parser/html/nsHtml5Tokenizer.cpp:391 5 xul.dll nsHtml5Parser::Parse parser/html/nsHtml5Parser.cpp:370 6 xul.dll nsHTMLDocument::WriteCommon content/html/document/src/nsHTMLDocument.cpp:1936 7 xul.dll nsHTMLDocument::Write content/html/document/src/nsHTMLDocument.cpp:1949 8 xul.dll nsIDOMHTMLDocument_Write obj-firefox/js/src/xpconnect/src/dom_quickstubs.cpp:17781 9 @0x80806e4 10 mozjs.dll js::mjit::EnterMethodJIT js/src/methodjit/MethodJIT.cpp:687 11 mozjs.dll js::mjit::JaegerShotAtSafePoint js/src/methodjit/MethodJIT.cpp:744 12 mozjs.dll js::Interpret js/src/jsinterp.cpp:2393 13 mozjs.dll js::ContextStack::pushInvokeFrame js/src/vm/Stack.cpp:636
Component: General → HTML: Parser
QA Contact: general → parser
I like to revise my last comment. (#12) Firefox is still going to crash if you use this script. But in the case, you are just seeing a huge memory usage, but no OOM, just try to make the string a bit longer and/or e.g. change "str += str;" to "str += str+str;" Greetings, Chris
"Infallible" malloc is going to lead to OOM crashes. It's unfortunate to have a way for Web content to trigger OOM reliably, but it doesn't really make sense to switch to "infallible" malloc and then change allocations back to fallible one by one. (Here, the problem is that Web content can drive the allocation amount too directly, but *any* allocation could be the last straw after Web content has driven the allocator to the verge of OOM.) However, in this particular case, a fix for bug 489820 could alleviate the problem by making it easier to use fallible allocation for certain buffers.
Depends on: 489820
Crash Signature: [@ operator new(unsigned int) | jArray<unsigned short, int>::jArray<unsigned short, int>(int) ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters()] → int>(int) ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters()] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsHtml5TreeBuilder::flushCharacters()] [@ operato…
Crash Signature: , int>(int) ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters()] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsHtml5TreeBuilder::flushCharacters()] → , int>(int) ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters()] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsHtml5TreeBuilder::flushCharacters()] [@ oper…
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Reopening because crash bugs **with testcases** should not be resolved **as WONTFIX** based on queries of crash-stats. Other resolutions may be appropriate for other reasons. (Crash signatures are not the same as bug identity; they're merely a search aid to find and group similar crashes. The bug may still be present, but the signature may have changed slightly, or the bug may even still be present with the same signature but there are simply no recent reports of crashes in that function.)
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
QA Whiteboard: qa-not-actionable
Severity: critical → S2

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: S2 → S3
Crash Signature: , int>(int) ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters()] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsHtml5TreeBuilder::flushCharacters()] [@ → , int>(int) ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsHtml5TreeBuilder::flushCharacters] [@
Summary: document.write DoS loop crash in [@ operator new(unsigned int) | jArray<unsigned short, int>::jArray<unsigned short, int>(int) ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters()] → document.write DoS loop crash in [@ operator new(unsigned int) | jArray<unsigned short, int>::jArray<unsigned short, int>(int) ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsHtml5TreeBuilder::flushCharacters]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: