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!

I reduced the HTML file to a simplified 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

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.

Comment 7 and comment 8 are reasonable ways to crash when OOM.

Since Firefox 6.0 trunk, the new signature for me on Win 7 is: @ 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?

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

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.

Closing because no crash reported since 12 weeks.

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