A page with more than 199 <b>'s inside each other crashes NGlayout nightly build 981008 and generates the following error message: VIEWER orsakade ett ogiltigt sidfel i modul RAPTORHTMLPARS.DLL på adress 014f:007910a2. Register: EAX=00000007 CS=014f EIP=007910a2 EFLGS=00010202 EBX=00abfcbe SS=0157 ESP=00abfa1c EBP=00abfa20 ECX=00000007 DS=0157 ESI=00008ce2 FS=344f EDX=01248c70 ES=0157 EDI=00abfc74 GS=0000 Byte på CS:EIP: 8b 48 08 8b 55 fc 8b 45 08 89 44 8a 0c 8b 4d fc Stackdump: 00000007 00abfa38 00794fe3 00000007 00abfa38 01248c70 00000000 00abfa64 00794886 00000007 00000007 fffffff8 01248c70 00793b59 00000007 007a8138 The computer is a AMD K6 with 64MB RAM.

Still crashes re-opening bug. See test case (sorry outside people - you can't see it).

Still crashes - re-opening bug. See test case (sorry outside people - you can't see it).

The bug is actually fixed, but the #define that is used to control the memory model was not. I've changed it to match the standard NS_DEBUG convention so that the right model is used in non-debug builds.

There's still a memory bug definitely taking place on Mac OS (2.8.99 build), and something taking place on the 2.4.99 Linux build. Specifically: * No crash on test page on Win32 build (2.4.99 build) * Mac OS build crashes trying to allocate memory (2.8.99 build) * Linux build segfaults after a 3-4 minute pause (2.4.99 build) Mac stack crawl follows. PowerPC unmapped memory exception at 0BA6CFD8 calloc+00FA0 Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 0BA85C44 03AF0280 PPC 0BA7CDC8 03AF0220 PPC 0BA7C628 03AF01E0 PPC 0B8A12E0 nsMacMessageSink::IsRaptorWindow(GrafPort*)+00E6C 03AF0100 PPC 0B8A1818 nsMacMessageSink::IsRaptorWindow(GrafPort*)+013A4 03AF00A0 PPC 0B9F99B0 Repeater::DoRepeaters(const EventRecord&)+00030 03AF0060 PPC 0B9F6134 TimerPeriodical::RepeatAction(const EventRecord&)+ 00048 03AF0010 PPC 0B9F5DEC TimerImpl::Fire()+00024 03AEFFD0 PPC 0B97B840 NS_OpenURL(nsIURL*, nsIInputStream**, nsIStreamListener*)+0016C 03AEFF90 PPC 0B95C8F0 NET_RegisterProtocolImplementation+05978 03AEFF40 PPC 0B958B20 NET_RegisterProtocolImplementation+01BA8 03AEFBB0 PPC 0B9753A0 TimingElapsedTimeToString+17BB0 03AEF740 PPC 0B974D20 TimingElapsedTimeToString+17530 03AEF6F0 PPC 0B94F1E0 03AEF690 PPC 0B97E2C8 NS_ShutdownINetService+02928 03AEF640 PPC 0B61E838 03AEF5F0 PPC 0B63A404 NS_NewOtherHTMLDTD(nsIDTD**)+081B0 03AEF590 PPC 0B639FE4 NS_NewOtherHTMLDTD(nsIDTD**)+07D90 03AEF540 PPC 0B63A0E4 NS_NewOtherHTMLDTD(nsIDTD**)+07E90 03AEF500 PPC 0B62E6B4 NS_NewNavHTMLDTD(nsIDTD**)+00A7C 03AEF4B0 PPC 0B62E938 NS_NewNavHTMLDTD(nsIDTD**)+00D00 03AEF460 PPC 0B638EF4 NS_NewOtherHTMLDTD(nsIDTD**)+06CA0 03AEF420 PPC 0B62DD74 NS_NewNavHTMLDTD(nsIDTD**)+0013C 03AEF3D0 PPC 0B62F2F4 NS_NewNavHTMLDTD(nsIDTD**)+016BC 03AEF310 PPC 0B62EFE0 NS_NewNavHTMLDTD(nsIDTD**)+013A8 03AEF250 PPC 0B631330 NS_NewNavHTMLDTD(nsIDTD**)+036F8 03AEF1F0 PPC 0B644AC0 NS_EntityToUnicode(const char*)+0194C 03AEF1A0 PPC 0BA6B498 operator delete(void*)+00014 03AEF140 PPC 0BA6BF5C free+00030 03AEF100 PPC 0BA6C89C calloc+00864 Closing log

Oops, this has actually been fixed from some time. Please verify.

Verified fixed using 5.3.99 AM Mac OS & Win32 (on NT4 SP3) build, and on 5.4.99 AM Linux build.

Department of completely unreal testcases has found that Mozilla 1999110208 craches when it gets 5001 nested <b>-tags, but not when it gets 4001. Narrower pinpointing became too boring since the rendering time is around 120 secs. (to compare with somthing like 1 for navigator). You get a message that looks like this, in your language of choice (stack error this time): MOZILLA orsakade ett stackfel i modul GKHTML.DLL på adressen 0177:601cdf75. Registrerar: EAX=0085b208 CS=0177 EIP=601cdf75 EFLGS=00010206 EBX=0085b1fc SS=017f ESP=00542000 EBP=00542208 ECX=0083c7e0 DS=017f ESI=00542270 FS=67ef EDX=0083c2b0 ES=017f EDI=0085aa80 GS=0000 Byte på CS:EIP: 53 56 57 8b 7d 10 8d 4d d0 33 f6 8b 07 51 57 ff Stackdump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Clearing Fixed resolution due to reopen of this bug.

Moving from M6 to M11 due to reopen. elig, can you see if this still happens with current build.

Martin already did before he re-opening it. ;)

This is crashig in style code. Forwarding to Pierre, along with a stack trace: nsHTMLSpanElement::GetTag(const nsHTMLSpanElement * const 0x02abb6cc, nsIAtom * & 0x00332b97) line 59 + 6 bytes SelectorMatches(nsIPresContext * 0x014398a0, nsCSSSelector * 0x014592e0, nsIContent * 0x02abb6cc, int 1) line 2305 PseudoEnumFunc(nsICSSStyleRule * 0x0145cefc, void * 0x00033354) line 2737 + 24 bytes RuleHash::EnumerateTagRules(nsIAtom * 0x01412460, void (nsICSSStyleRule *, void *)* 0x0196a070 PseudoEnumFunc(nsICSSStyleRule *, void *), void * 0x00033354) line 347 + 13 bytes CSSRuleProcessor::RulesMatching(CSSRuleProcessor * const 0x0218e570, nsIPresContext * 0x014398a0, nsIAtom * 0x01434960, nsIContent * 0x02abb6cc, nsIAtom * 0x01412460, nsIStyleContext * 0x02ceed50, nsISupportsArray * 0x02ceebe0) line 2805 EnumPseudoRulesMatching(nsISupports * 0x0218e570, void * 0x000333dc) line 701 nsSupportsArray::EnumerateForwards(nsSupportsArray * const 0x0218e5b0, int (nsISupports *, void *)* 0x01887c00 EnumPseudoRulesMatching(nsISupports *, void *), void * 0x000333dc) line 352 + 20 bytes StyleSetImpl::ProbePseudoStyleFor(nsIPresContext * 0x014398a0, nsIContent * 0x02abb6cc, nsIAtom * 0x01412460, nsIStyleContext * 0x02ceed50, int 0) line 787 nsPresContext::ProbePseudoStyleContextFor(nsPresContext * const 0x014398a0, nsIContent * 0x02abb6cc, nsIAtom * 0x01412460, nsIStyleContext * 0x02ceed50, int 0, nsIStyleContext * * 0x000334a8) line 461 + 42 bytes nsCSSFrameConstructor::CreateGeneratedContentFrame(nsIPresContext * 0x014398a0, nsFrameConstructorState & {...}, nsIFrame * 0x02ceec30, nsIContent * 0x02abb6cc, nsIStyleContext * 0x02ceed50, nsIAtom * 0x01412460, int 0, nsIFrame * * 0x000334fc) line 736

5001 nested tags is probably not an M11 stopper :-) Feel free to move off list.

It crashes in various places, not just in the style system, because of a lack of memory. It's quite a good test case for the time&space teams. I'll look into it later, hopefully before we ship.

Pushing my M15 bugs to M16

Adding "crash" keyword to all known open crasher bugs.

Marc -- another easy one for you to kill.

Actually, I'm not sure it's an easy one to fix. My opinion is that this page creates an out-of-mem condition which causes crashes in various places.

Point of crash vary from build-to-build because the page is causing a stack overflow due to recursive frame construction. Total memory usage is not that high, however the stack is a limited resource. I think Pierre is correct; this is a very difficult problem because solving it means either redesigning how the frames are created (i.e. remove recursion) or adding some code to artificially limit the recursion. Alternately, we could try to collapse the nesting in the content model: in this (contrived) case most of the nested <B> tags make no difference to the layout and could be collapsed, though in a real-world case this might not be possible (in the real world we probably won't have such deeply nested tags either). Since we do not want to crash I suggest we at least create a frame-nesting-depth limit and bail before we crash. Fundamentally changing the frame creation model make me, well, nervous.

A decision on this one requires feet that are much 'wetter' than mine. In other words, passing off to a more experienced engineer to decide what to do. Please note my previous comment re: recursion as the root of the problem.

Nisheeth -- this has gone from what looked trivial to a problem involving a deeply nested stack problem in frame construction. Please take a look, and see what we can do about stack usage.

Troy, we crash on a page with 5001 nested <B> tags. Is this a known problem that we are going to try to tackle later on? Or, should I spend some time analyzing this?

It's most likely a known issue, although it depends on why we crash. The stack trace looks like the parser, in which case this is not a known issue. If that's really the case, then change the component to Parser and re-assign to Harish. It maybe because of residual style

*** Bug 27173 has been marked as a duplicate of this bug. ***

I closed bug 27173 as dup of this one. It contained a very cool testcase that has thousands of un-terminated FONT tags and shows that this bug is not as hypothetical as some may have thought. The testcase is at http://rio.dhs.org/penguin.html

*** This bug has been marked as a duplicate of 18480 ***

Making a random guess that janc is the right person to verify this bug.

I'll do it. Marking Verified. These 2 bugs went through different channels and nobody noticed they were dups for quite some time.