130251 - crash with the fieldset tag [@ nsBlockBandData::Init][@ nsSpaceManager::GetTranslation]

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[Roberto Busolin]

every time I run a page with these tags mozilla 0.9.9 crash, the 0.9.8 and the
and the preceding versions instead do not have any problem

<fieldset id="fieldset1" style="position:absolute; width:300; height:300;
top:20; left:50;">
<legend><font size="5" ><b>Newsletter</b></font></legend>

Comment 1

[Boris Zbarsky [:bzbarsky]]

#0  nsSpaceManager::GetTranslation (this=0x0, aX=@0xbfffd81c, aY=@0xbfffd820)
    at ../../../base/src/nsSpaceManager.h:192
#1  0x41ba41f9 in nsBlockBandData::Init (this=0xbfffd80c, aSpaceManager=0x0, 
    aSpace=@0xbfffd7a0) at nsBlockBandData.cpp:72
#2  0x41bb5518 in nsBlockReflowState::nsBlockReflowState (this=0xbfffd780, 
    aReflowState=@0xbfffdb78, aPresContext=0x86f8ad8, aFrame=0x8725e9c, 
    aMetrics=@0xbfffdc5c, aBlockMarginRoot=0) at nsBlockReflowState.cpp:149
#3  0x41ba67c7 in nsBlockFrame::Reflow (this=0x8725e9c, aPresContext=0x86f8ad8, 
    aMetrics=@0xbfffdc5c, aReflowState=@0xbfffdb78, aStatus=@0xbfffdeb0)
    at nsBlockFrame.cpp:733
#4  0x41c74a03 in nsLegendFrame::Reflow (this=0x8725e9c, aPresContext=0x86f8ad8, 
    aDesiredSize=@0xbfffdc5c, aReflowState=@0xbfffdb78, aStatus=@0xbfffdeb0)
    at nsLegendFrame.cpp:119


(gdb) frame 0
#0  nsSpaceManager::GetTranslation (this=0x0, aX=@0xbfffd81c, aY=@0xbfffd820)
    at ../../../base/src/nsSpaceManager.h:192
192       void GetTranslation(nscoord& aX, nscoord& aY) const { aX = mX; aY = mY; }
(gdb) p aX
$1 = (nscoord &) @0xbfffd81c: 0
(gdb) p aY
$2 = (nscoord &) @0xbfffd820: 0
(gdb) p this
$3 = (nsSpaceManager *) 0x0
(gdb) frame 1
#1  0x41ba41f9 in nsBlockBandData::Init (this=0xbfffd80c, aSpaceManager=0x0, 
    aSpace=@0xbfffd7a0) at nsBlockBandData.cpp:72
72        aSpaceManager->GetTranslation(mSpaceManagerX, mSpaceManagerY);
(gdb) p aSpaceManager
$4 = (nsSpaceManager *) 0x0
(gdb) frame 2
#2  0x41bb5518 in nsBlockReflowState::nsBlockReflowState (this=0xbfffd780, 
    aReflowState=@0xbfffdb78, aPresContext=0x86f8ad8, aFrame=0x8725e9c, 
    aMetrics=@0xbfffdc5c, aBlockMarginRoot=0) at nsBlockReflowState.cpp:149
149       mBand.Init(mSpaceManager, mContentArea);
(gdb) p mSpaceManager
$5 = (nsSpaceManager *) 0x0

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Full stack

This is happening on current trunk as well.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: minimal testcase (will cause crash in build 2002-03-12 morning)

Comment 4

[Stefan [:stefanh]]

Testcase WFM with Mac OS 9.1 build 2002031106

Comment 5

[Chris Petersen]

Here's a stack trace in OS X (March 12 build - 2002-03-12-08):

Date/Time:  2002-03-12 15:36:59 -0800
OS Version: 10.1.3 (Build 5Q45)
Host:       localhost

Command:    Mozilla
PID:        319

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000004

Thread 0 Crashed:
 #0   0x027d2af8 in nsBlockBandData::Init(nsSpaceManager *, nsSize const &)
 #1   0x028d25ec in 0x28d25ec
 #2   0x027a1840 in 0x27a1840
 #3   0x027c0020 in Reflow__13nsLegendFrameFP14nsIPresContextR19nsHTMLReflowMetric
 #4   0x02700aac in ReflowChild__16nsContainerFrameFP8nsIFrameP14nsIPresContextR19
 #5   0x027bf0ac in 0x27bf0ac
 #6   0x0281eb14 in ReflowAbsoluteFrame__25nsAbsoluteContainingBlockFP8nsIFrameP14
 #7   0x0281e3f8 in Reflow__25nsAbsoluteContainingBlockFP8nsIFrameP14nsIPresContex
 #8   0x027a1ddc in nsBlockFrame::Reflow(nsIPresContext *, nsHTMLReflowMetrics &)
 #9   0x02700aac in ReflowChild__16nsContainerFrameFP8nsIFrameP14nsIPresContextR19
 #10  0x028b2310 in CanvasFrame::Reflow(nsIPresContext *, nsHTMLReflowMetrics &,  &)
 #11  0x0285e934 in Reflow__19nsBoxToBlockAdaptorFR16nsBoxLayoutStateP14nsIPresCon
 #12  0x0285e374 in nsBoxToBlockAdaptor::DoLayout(nsBoxLayoutState &)
 #13  0x02858f5c in nsBox::Layout(nsBoxLayoutState &)
 #14  0x02899790 in 0x2899790
 #15  0x02858f5c in nsBox::Layout(nsBoxLayoutState &)
 #16  0x02861898 in LayoutChildAt__14nsContainerBoxFR16nsBoxLayoutStateP6nsIBoxRC6
 #17  0x0284c2fc in nsGfxScrollFrameInner::LayoutBox(nsBoxLayoutState &, nsIBox *)
 #18  0x0284c7dc in 0x284c7dc
 #19  0x0284c3b4 in nsGfxScrollFrame::DoLayout(nsBoxLayoutState &)
 #20  0x02858f5c in nsBox::Layout(nsBoxLayoutState &)
 #21  0x02818db0 in nsBoxFrame::Reflow(nsIPresContext *, nsHTMLReflowMetrics &,
 const &)
 #22  0x0284b430 in Reflow__16nsGfxScrollFrameFP14nsIPresContextR19nsHTMLReflowMet
 #23  0x02700aac in ReflowChild__16nsContainerFrameFP8nsIFrameP14nsIPresContextR19
 #24  0x027e8f18 in Reflow__13ViewportFrameFP14nsIPresContextR19nsHTMLReflowMetric
 #25  0x02774730 in Dispatch__19nsHTMLReflowCommandFP14nsIPresContextR19nsHTMLRefl
 #26  0x02725c84 in ProcessReflowCommand__9PresShellFR11nsVoidArrayiR19nsHTMLReflo
 #27  0x02725e6c in PresShell::ProcessReflowCommands(int)
 #28  0x027257e8 in HandlePLEvent(ReflowEvent *)
 #29  0x005f4dc0 in PL_HandleEvent
 #30  0x005f4c2c in PL_ProcessPendingEvents
 #31  0x0059a71c in nsEventQueueImpl::ProcessPendingEvents(void)
 #32  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #33  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #34  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #35  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #36  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #37  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #38  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #39  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #40  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #41  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #42  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #43  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #44  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #45  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #46  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #47  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #48  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #49  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #50  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #51  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #52  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #53  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #54  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #55  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #56  0x0059a7c4 in nsEventQueueImpl::ProcessPendingEvents(void)
 #57  0x0245888c in nsMacNSPREventQueueHandler::ProcessPLEventQueue(void)
 #58  0x02458650 in nsMacNSPREventQueueHandler::RepeatAction(EventRecord const &)
 #59  0x010e9b14 in Repeater::DoRepeaters(EventRecord const &)
 #60  0x0246c8f8 in nsMacMessagePump::DispatchEvent(int, EventRecord *)
 #61  0x0246c4d0 in nsMacMessagePump::DoMessagePump(void)
 #62  0x0246be4c in nsAppShell::Run(void)
 #63  0x01a832fc in nsAppShellService::Run(void)
 #64  0x004cc224 in main1(int, char **, nsISupports *)
 #65  0x004cccfc in main

Thread 1:
 #0   0x7000497c in syscall
 #1   0x70557600 in BSD_waitevent
 #2   0x70554b80 in CarbonSelectThreadFunc
 #3   0x7002054c in _pthread_body

Thread 2:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x705593ec in CarbonOperationThreadFunc
 #3   0x7002054c in _pthread_body

Thread 3:
 #0   0x70044cf8 in semaphore_timedwait_signal_trap
 #1   0x70044cd8 in semaphore_timedwait_signal
 #2   0x70283ea4 in TSWaitOnConditionTimedRelative
 #3   0x7027d748 in TSWaitOnSemaphoreCommon
 #4   0x702c2078 in TimerThread
 #5   0x7002054c in _pthread_body

Thread 4:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x70250ab0 in TSWaitOnCondition
 #3   0x7027d730 in TSWaitOnSemaphoreCommon
 #4   0x70243d14 in AsyncFileThread
 #5   0x7002054c in _pthread_body

Thread 5:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x7055b884 in CarbonInetOperThreadFunc
 #3   0x7002054c in _pthread_body

Thread 6:
 #0   0x70000978 in mach_msg_overwrite_trap
 #1   0x70005a04 in mach_msg
 #2   0x7017bf98 in __CFRunLoopRun
 #3   0x701b7100 in CFRunLoopRunSpecific
 #4   0x7017b8e0 in CFRunLoopRunInMode
 #5   0x7061be08 in
XIOAudioDeviceManager::NotificationThread(XIOAudioDeviceManager *)
 #6   0x706141c0 in CAPThread::Entry(CAPThread *)
 #7   0x7002054c in _pthread_body

Thread 7:
 #0   0x70000978 in mach_msg_overwrite_trap
 #1   0x70005a04 in mach_msg
 #2   0x70026a2c in _pthread_become_available
 #3   0x70026724 in pthread_exit
 #4   0x70020550 in _pthread_body

PPC Thread State:
  srr0: 0x027d2af8 srr1: 0x0000f030                vrsave: 0x00000000
   xer: 0x00000008   lr: 0x028d2850  ctr: 0x0272b280   mq: 0x00000000
    r0: 0x00000000   r1: 0xbfffcb70   r2: 0x02953000   r3: 0xbfffcde0
    r4: 0x00000000   r5: 0xbfffcd78   r6: 0x00000020   r7: 0x00000006
    r8: 0x00000000   r9: 0x00000000  r10: 0x00000003  r11: 0x00000000
   r12: 0x0294e604  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
   r16: 0x00000000  r17: 0x00000000  r18: 0x00000000  r19: 0xbfffe58c
   r20: 0x02996408  r21: 0x00000000  r22: 0x00000000  r23: 0x067fe59c
   r24: 0x067fe7b8  r25: 0x0434ac80  r26: 0xbfffd590  r27: 0xbfffd1a4
   r28: 0x0434ac80  r29: 0x067fe7b8  r30: 0xbfffd0c0  r31: 0xbfffd1a4

Comment 6

[Thomas Lußnig]

#person-login fieldset       { position:absolute; top:50px; left:50px;
width:300px; background-color:#cccccc; }

Since that information also crash i think the command Point is that
positioning absolute an fildset crash mozilla.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Boris Zbarsky [:bzbarsky]]

This crashes on one of the sample XUL docs on mozilla.org too (the doc includes
an <html:fieldset>).

Comment 9

[Marc Attinasi]

I've seen this before - problem is I don't remember where...

The space manager is null for the reflowState, that is causing the crash because
the blockBandData assumes that the space manager passed in is non-null. The
assertion in nsBlockReflowState::nsBlockReflowState:
  NS_ASSERTION(mSpaceManager,
               "SpaceManager should be set in nsBlockReflowState" );
is the first indication fo the problem, and it then checks for null and prevents
a crash, but then mBand.Init is called and it does crash.

We can check for null, but I think it better to find out why we are not creating
the space manager.

Comment 10

[Chris Waterson]

You probably saw crashes like this when I took the space manager out of
nsBoxToBlockAdaptor a few months ago. We really want to find out why someone is
not getting a space manager created -- want me to take a look?

Comment 11

[Vadim Berezniker]

bug 135368 sounds like this bug with some other circumstances.
in that bug, the testcase is the following:
<table style="position: absolute;"><tr><form>

and the crash happens in the same place as this crash
if someone knows it for sure, then please dupe the other bug to this one

Comment 12

[Matthias Versen [:Matti]]

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

Comment 13

[Marc Attinasi]

I wonder if we need to copy the NS_BLOCK_SPACE_MGR bit from the out-of-flow
frame to the placeholder... At any rate, it looks like the bit is being ignored
on the positioned frame, and that ReflowAbsoluteFrame is not doing anything to
create a space manager for the positioned frame either.

It seems a little strange that the AbsoluteConainingBlock should have to create
the space manager for the kidReflowState when it goes to reflow the positioned
kid, but maybe that is what has to happen?

Comment 14

[karnaze (gone)]

Adding the url http://www.schaapskudde.nl from bug 77630.

Comment 15

[Marc Attinasi]

Attachment: PATCH: create space manager in nsAbsoluteContainingBlock for reflowing all the children.

Fixes the crash in the attached testcases (fieldset and table) and the URL that
karnaze posted, though that URL has some other problems as well.

Comment 16

[Chris Waterson]

Since we have a test case here, would it be possible to figure out why the
NS_BLOCK_SPACE_MGR bit isn't getting set? Is something going wrong with the
construction of the absolute containing block in the frame ctor?

The patch certainly is reasonable...but it seems like it ought not be necessary...

Comment 17

[Marc Attinasi]

I'll look some more, Chris. I did force the NS_BLOCK_SPACE_MGR block on the
AbsoluteContainingBlock in the frame constructor, but it didn't make any
difference. I think it is the children of the AbsoluteContainingblock that need
the bit, but I'm not sure so I'll do some more learning.

Comment 18

[Marc Attinasi]

Attachment: patch to restore the space manager in the reflow state after absolute items are reflowed

So the problem was not with a lack of SPACE_MGR bits, but rather with how the
block frame managed the space manager that it creatd in response to that bit.
Specifically, the block was creating the space manager but then clearing it out
of the reflow state _before_ the absolute items were handled. The simple patch
is to simply delay restoring the old space manager (and deleting the newly
created one) until after the absolute items are reflowed. Thanks for the gentle
prodding, Chris ;)

Comment 19

[Marc Attinasi]

I would like to clean up how the BlockFrame does the manipulation of the space
manager in the reflow state - maybe later. It is currently casting away const to
poke the space manager pointer in, but I'd prefer if it did the alternate
approach of making a copy of the reflow state and manipulating that, though it
is prbably somewhat less efficient since it has to copy the reflow state to a
local...

Comment 20

[Marc Attinasi]

Attachment: testcase that exercises incremental reflow of the positioned fieldset too, and include the positoioned table bits

Comment 21

[Marc Attinasi]

Attachment: revised patch to handle the incremental reflow as well

Waterson pointed out the incremental reflow case, and sure enough, that needs
the space manager set too, thus this patch.

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I recall commenting on a different bug about this same problem.

I think this solution doesn't seem like the real fix, but rather a hack that
happens to fix the problem, or something like that.  (But actually, why doesn't
the BODY already have a space manager?)  Intuitively, I think any absolutely
positioned element should automatically have its own space manager, since
anything that establishes a new absolute positioning formatting context also
should establish a new block formatting context (I think those are the terms I
used at the Redmond City CSS WG F2F).

Maybe I'm confused, though.  With which frame is the space manager that the
legend frame ends up accessing (instead of null) associated?

Comment 23

[Marc Attinasi]

David, I think what you are intuituively expecting to happen is what is
happening. The Fieldset Frame is absolutely positioned and it causes a space
manager to be created for the reflow of its children. The legend frame is
acessing that space manager of the fieldset frame in its reflow. 

The HTML element also has a space manager established for it, and that is the
one that has to be 'installed' in the reflow state for the FieldSet frame's
reflow, which happens in the context of the absoluteContainer.Reflow /
IncrementalReflow methods. The patch makes sure that the Fieldset frame's reflow
has a space manager, the one from the HTML frame's reflow. The legend frame was
not the problem. Prior to the patch, the space manager for the HTML element was
NOT being set into the reflow state for the reflow of the Fieldset Frame, and it
was ASSERTING / crashing.

Why does it seem like a hack? It seems totally logical to me that the space
manager for the container needs to be in the parent reflow state when reflowing
the children, even if they are positioned children. The positioned frames
install their own space manager to pass to _their_ children.

Comment 24

[Alexandru Savulov]

ok here is what i think:

if the NS_BLOCK_SPACE_MGR flag is set we end up creating a space manager anyway.
the fact that Marc's patch fixes the crashers is that the flag is set and we do
need a space manager anyway. There are 2 cases here

1. if (eReflowReason_Incremental == aReflowState.reason) (at the beginning)
2. if (NS_SUCCEEDED(rv) && mAbsoluteContainer.HasAbsoluteFrames())

now the question is do we want to provide the space manager from the current
block's reflow method before we enter the mAbsoluteContainer methods? for case
#1 I think that it can be also created inside the absolute container, but in the
second case we would end up in creating, destroying and re-creating an other
space manager for the stuff inside the absolute container (remember, the flag
NS_BLOCK_SPACE_MGR is already set in this block's mState so we will create a
space manager that we preheaps do need only for the absolute container but we
destroy it first and re-create another one inside).

ok, since we don't hurry, could we have more oppinins on this one please? i
think that Marc's patch is ok for preventing crashes be cause in the case we
don't have   an inremental reflow and/or absloute positioned elements, the patch
just changes the order things happen and that's ok (there are no dependencies
between the parts of the method that get switched). 

Marc: just one thing 

is it possible to move that 

  if (IsFrameTreeTooDeep(aReflowState, aMetrics)) {
....
    aStatus = NS_FRAME_COMPLETE;
    return NS_OK;
  }

in front of the creation of the new space manager in your patch? would that
change have deep implications? i see that we have some potential mem leaks
related to this space manager if the reflow fails anyway. hmmm

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 78757 [details] [diff] [review]
revised patch to handle the incremental reflow as well

It looks like you're going to leak a space manager (and perhaps also end up
using the wrong one for siblings) in the case where the absolute container
handles the reflow since there's an early return.

Comment 26

[Marc Attinasi]

good catch on the leak - thanks, I'll fix that.

Comment 27

[Chris Waterson]

Comment on attachment 78757 [details] [diff] [review]
revised patch to handle the incremental reflow as well

sr=waterson. looks great!

Comment 28

[Alexandru Savulov]

complete crash stack with comments.


 ** crash

nsIFrame::GetStyleData(nsStyleStructID eStyleStruct_Display, const 
nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineLi
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineList_ite

 ** here we reflow a line that's empty

nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 223
nsBlockFrame::Reflow(nsBlockFrame * const 0x03b14d58, nsIPresContex
nsContainerFrame::ReflowChild(nsIFrame * 0x03b14d58, nsIPresContext
CanvasFrame::Reflow(CanvasFrame * const 0x03b01190, nsIPresContext 
nsBoxToBlockAdaptor::Reflow(nsBoxLayoutState & {...}, nsIPresContex
nsBoxToBlockAdaptor::DoLayout(nsBoxToBlockAdaptor * const 0x03b14cb
nsBox::Layout(nsBox * const 0x03b14cbc, nsBoxLayoutState & {...}) l
nsScrollBoxFrame::DoLayout(nsScrollBoxFrame * const 0x03b0168c, nsB
nsBox::Layout(nsBox * const 0x03b0168c, nsBoxLayoutState & {...}) l
nsContainerBox::LayoutChildAt(nsBoxLayoutState & {...}, nsIBox * 0x
nsGfxScrollFrameInner::LayoutBox(nsBoxLayoutState & {...}, nsIBox *
nsGfxScrollFrameInner::Layout(nsBoxLayoutState & {...}) line 1217
nsGfxScrollFrame::DoLayout(nsGfxScrollFrame * const 0x03b01494, nsB
nsBox::Layout(nsBox * const 0x03b01494, nsBoxLayoutState & {...}) l
nsBoxFrame::Reflow(nsBoxFrame * const 0x03b0145c, nsIPresContext * 
nsGfxScrollFrame::Reflow(nsGfxScrollFrame * const 0x03b0145c, nsIPr
nsContainerFrame::ReflowChild(nsIFrame * 0x03b0145c, nsIPresContext
ViewportFrame::Reflow(ViewportFrame * const 0x03b01154, nsIPresCont
nsHTMLReflowCommand::Dispatch(nsIPresContext * 0x039b5028, nsHTMLRe
PresShell::ProcessReflowCommand(nsVoidArray & {...}, int 0, nsHTMLR
PresShell::ProcessReflowCommands(int 0) line 6338

 ** the press shell flushes th reflow commands

PresShell::FlushPendingNotifications(PresShell * const 0x037cd3a8, 
nsDocument::FlushPendingNotifications(nsDocument * const 0x03ad7660
nsHTMLDocument::FlushPendingNotifications(nsHTMLDocument * const 0x

 ** the window list flushes the pending notifications to retrive a
    consistent length (is my guess)

nsDOMWindowList::GetLength(nsDOMWindowList * const 0x039a2e80, unsi
GlobalWindowImpl::GetLength(GlobalWindowImpl * const 0x0399b49c, un
XPTC_InvokeByIndex(nsISupports * 0x0399b49c, unsigned int 59, unsig
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNati
XPCWrappedNative::GetAttribute(XPCCallContext & {...}) line 1823 +

 ** i'm not really an expert here but we end up calling a method with 
    the index 59 on the GlobalWindowImpl: GetLength

XPC_WN_GetterSetter(JSContext * 0x02b69008, JSObject * 0x02d8f108, 
js_Invoke(JSContext * 0x02b69008, unsigned int 0, unsigned int 2) l
js_InternalInvoke(JSContext * 0x02b69008, JSObject * 0x02d8f108, lo
js_GetProperty(JSContext * 0x02b69008, JSObject * 0x02d8f108, long 
js_Interpret(JSContext * 0x02b69008, long * 0x0012942c) line 2576 +
js_Invoke(JSContext * 0x02b69008, unsigned int 1, unsigned int 2) l
nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJSClass * const 0x02deb
nsXPCWrappedJS::CallMethod(nsXPCWrappedJS * const 0x03aa05a8, unsig
PrepareAndDispatch(nsXPTCStubBase * 0x03aa05a8, unsigned int 3, uns
SharedStub() line 139
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x03a
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 
nsXULElement::HandleDOMEvent(nsXULElement * const 0x02e0dcf8, nsIPr
nsXULElement::HandleDOMEvent(nsXULElement * const 0x02e0df78, nsIPr
nsXULElement::HandleDOMEvent(nsXULElement * const 0x02e11ff8, nsIPr
nsXULElement::HandleDOMEvent(nsXULElement * const 0x038fab48, nsIPr
nsXULElement::HandleDOMEvent(nsXULElement * const 0x03897040, nsIPr
nsXULElement::HandleDOMEvent(nsXULElement * const 0x0392e258, nsIPr
nsXULElement::HandleChromeEvent(nsXULElement * const 0x0392e268, ns
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x0399b49
nsDocument::HandleDOMEvent(nsDocument * const 0x03ad7660, nsIPresCo

 ** NS_GOTFOCUS gets translated to NS_FOCUS_CONTENT

nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x0
PresShell::HandleEventInternal(nsEvent * 0x0012bdfc, nsIView * 0x03
PresShell::HandleEvent(PresShell * const 0x037cd3ac, nsIView * 0x03
nsViewManager::HandleEvent(nsView * 0x03b17a20, nsGUIEvent * 0x0012
nsView::HandleEvent(nsViewManager * 0x037e7cc8, nsGUIEvent * 0x0012
nsViewManager::DispatchEvent(nsViewManager * const 0x037e7cc8, nsGU
HandleEvent(nsGUIEvent * 0x0012bdfc) line 83
nsWindow::DispatchEvent(nsWindow * const 0x03b17aec, nsGUIEvent * 0
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012bdfc) line 886
nsWindow::DispatchFocus(unsigned int 105, int 1) line 4907 + 15 byt

 ** WM_SETFOCUS gets dispatched, DispatchFocus receives NS_GOTFOCUS(105)

nsWindow::ProcessMessage(unsigned int 7, unsigned int 395000, long 
nsWindow::WindowProc(HWND__ * 0x001d0708, unsigned int 7, unsigned 
USER32! 77e12e98()
USER32! 77e139a3()
USER32! 77e1395f()
NTDLL! 77fa032f()

 ** the view's window get's destroyed with ::DestroyWindow()

nsView::~nsView() line 163
nsView::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsView::Destroy(nsView * const 0x03ab1f80) line 260 + 34 bytes

 ** the frame destroys the view

nsFrame::Destroy(nsFrame * const 0x03aae504, nsIPresContext * 0x039
nsFrameList::DestroyFrames(nsIPresContext * 0x039b5028) line 131
nsContainerFrame::Destroy(nsContainerFrame * const 0x03aae474, nsIP
nsLineBox::DeleteLineList(nsIPresContext * 0x039b5028, nsLineList &
nsBlockFrame::Destroy(nsBlockFrame * const 0x03b181b0, nsIPresConte

 ** we destroy the frame before removing the line

nsBlockFrame::DoRemoveFrame(nsIPresContext * 0x039b5028, nsIFrame *
nsBlockFrame::RemoveFrame(nsBlockFrame * const 0x03b14d58, nsIPresC
FrameManager::RemoveFrame(FrameManager * const 0x03888b28, nsIPresC

 ** the old content is removed 

nsCSSFrameConstructor::ContentRemoved(nsCSSFrameConstructor * const
nsCSSFrameConstructor::RecreateFramesForContent(nsIPresContext * 0x
nsCSSFrameConstructor::ProcessRestyledFrames(nsCSSFrameConstructor 
PresShell::ReconstructStyleData(PresShell * const 0x037cd3a8, int 0
PresShell::StyleSheetDisabledStateChanged(PresShell * const 0x037cd
nsDocument::SetStyleSheetDisabledState(nsIStyleSheet * 0x03959068, 

 ** the style sheet is disabled

CSSStyleSheetImpl::SetDisabled(CSSStyleSheetImpl * const 0x0395906c
XPTC_InvokeByIndex(nsISupports * 0x0395906c, unsigned int 5, unsign
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNati
XPCWrappedNative::SetAttribute(XPCCallContext & {...}) line 1826 + 
XPC_WN_GetterSetter(JSContext * 0x02b69008, JSObject * 0x02d8fe18, 
js_Invoke(JSContext * 0x02b69008, unsigned int 1, unsigned int 2) l
js_InternalInvoke(JSContext * 0x02b69008, JSObject * 0x02d8fe18, lo
js_SetProperty(JSContext * 0x02b69008, JSObject * 0x02d8fe18, long 
js_Interpret(JSContext * 0x02b69008, long * 0x0012d8f0) line 2587 +
js_Invoke(JSContext * 0x02b69008, unsigned int 1, unsigned int 2) l
js_InternalInvoke(JSContext * 0x02b69008, JSObject * 0x02d5d548, lo
JS_CallFunctionValue(JSContext * 0x02b69008, JSObject * 0x02d5d548,
nsJSContext::CallEventHandler(nsJSContext * const 0x02c1e280, void 
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x02e18410
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x02e
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 
nsXULElement::HandleDOMEvent(nsXULElement * const 0x02e190d8, nsIPr
nsXULElement::HandleDOMEvent(nsXULElement * const 0x03938880, nsIPr
nsXULElement::HandleDOMEvent(nsXULElement * const 0x03b88d10, nsIPr
nsXULElement::HandleDOMEvent(nsXULElement * const 0x03cbce70, nsIPr
nsXULElement::HandleDOMEvent(nsXULElement * const 0x038fe008, nsIPr
PresShell::HandleDOMEventWithTarget(PresShell * const 0x019751c8, n
nsMenuFrame::Execute() line 1684
nsMenuFrame::HandleEvent(nsMenuFrame * const 0x03cbab38, nsIPresCon
PresShell::HandleEventInternal(nsEvent * 0x0012f8d0, nsIView * 0x03
PresShell::HandleEvent(PresShell * const 0x019751cc, nsIView * 0x03
nsViewManager::HandleEvent(nsView * 0x03c41930, nsGUIEvent * 0x0012
nsView::HandleEvent(nsViewManager * 0x02c56958, nsGUIEvent * 0x0012
nsViewManager::DispatchEvent(nsViewManager * const 0x02c56958, nsGU
HandleEvent(nsGUIEvent * 0x0012f8d0) line 83

 ** the UI event gets handled

nsWindow::DispatchEvent(nsWindow * const 0x03c419fc, nsGUIEvent * 0
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f8d0) line 886
nsWindow::DispatchMouseEvent(unsigned int 301, unsigned int 0, nsPo
ChildWindow::DispatchMouseEvent(unsigned int 301, unsigned int 0, n
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 308
nsWindow::WindowProc(HWND__ * 0x000606ea, unsigned int 514, unsigne
USER32! 77e12e98()
USER32! 77e130e0()
USER32! 77e15824()
nsAppShellService::Run(nsAppShellService * const 0x0183fcf8) line 3
main1(int 2, char * * 0x00277780, nsISupports * 0x00000000) line 14
main(int 2, char * * 0x00277780) line 1763 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e97d08()

Comment 29

[Alexandru Savulov]

OOPS! SORRY I POSTED THE STACK ON THE WRONG BUG!

DISREGARD PREVIOUS COMMENT! SORRY!

Comment 30

[Alexandru Savulov]

Comment on attachment 78757 [details] [diff] [review]
revised patch to handle the incremental reflow as well

r= alexsavulov 
(including the changes we spoke about)

Comment 31

[Boris Zbarsky [:bzbarsky]]

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

Comment 32

[Håkan Waara]

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

Comment 33

[Marc Attinasi]

Checked in to trunk:

/cvsroot/mozilla/layout/html/base/src/nsBlockFrame.cpp,v  <--  nsBlockFrame.cpp
new revision: 3.501; previous revision: 3.500

Comment 34

[Jay Patel [:jay]]

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

Comment 35

[Jay Patel [:jay]]

Adding topcrash keyword and [@ nsBlockBandData::Init] to summary for tracking. 
This has been a topcrash with recent MozillaTrunk builds:

nsBlockBandData::Init   14
		 121860 	 VERI 	 FIXE 	 [e-mail] 	 mozilla0.9.9 	 2002-02-11 
BBID range: 5020221 - 5341265
Min/Max Seconds since last crash: 8 - 166810
Min/Max Runtime: 8 - 166810
Crash data range: 2002-04-09 to 2002-04-18
Build ID range: 2002040906 to 2002041806
Keyword List : bug(4), load(4), 
Stack Trace: 

	 nsBlockBandData::Init
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockBandData.cpp  line 72]
	 nsBlockReflowState::nsBlockReflowState
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowState.cpp  line 152]
	 nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 735]
	 nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 807]
	 nsTableRowFrame::ReflowChildren
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp  line 1117]
	 nsTableRowFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp  line 1461]
	 nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 807]
	 nsTableRowGroupFrame::ReflowChildren
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp 
line 449]
	 nsTableRowGroupFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp 
line 1213]
	 nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 807]
	 nsTableFrame::ReflowChildren
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp  line 3460]
	 nsTableFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp  line 2097]
	 nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 807]
	 nsTableOuterFrame::OuterReflowChild
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp  line 1028]
	 nsTableOuterFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp  line 1616]
	 nsAbsoluteContainingBlock::ReflowAbsoluteFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsAbsoluteContainingBlock.cpp
 line 442]
	 nsAbsoluteContainingBlock::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsAbsoluteContainingBlock.cpp
 line 227]
	 nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 1015]
	 nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 807]
	 CanvasFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp  line 565]
	 nsBoxToBlockAdaptor::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line 837]
	 nsBoxToBlockAdaptor::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line 619]
	 nsBox::Layout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1052]
	 nsScrollBoxFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp  line 395]
	 nsBox::Layout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1052]
	 nsBoxFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1001]
	 nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 807]
	 ViewportFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp  line 588]
	 nsHTMLReflowCommand::Dispatch
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowCommand.cpp  line 224]
	 PresShell::ProcessReflowCommand
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 6189]
	 PresShell::ProcessReflowCommands
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 6244]
	 ReflowEvent::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 6100]
	 PL_HandleEvent
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 597]
	 PL_ProcessPendingEvents
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 530]
	 _md_EventReceiverProc
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 1078]
	 nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp  line 309]
	 main1
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1430]
	 main
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1765]
	 WinMain
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1783]
	 WinMainCRTStartup()
	 KERNEL32.DLL + 0xd326 (0x77e8d326)
 
 	Source File :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/base/src/nsBlockBandData.cpp
line : 72
     (5341265)	URL: http://dinah.sourceforge.net/orkfia/
     (5303106)	URL: http://dinah.sourceforge.net/orkfia/
     (5303106)	Comments: crash on page-load
     (5302755)	URL: http://dinah.sourceforge.net/orkfia/
     (5302755)	Comments: tried to load the page again
     (5302745)	URL: http://dinah.sourceforge.net/orkfia/
     (5302745)	Comments: tried to load the page
     (5291481)	Comments: XUL test page
     (5224150)	Comments: just loading a page
     (5026795)	URL: http://www.ktxt.net
     (5026795)	Comments: http://bugzilla.mozilla.org/show_bug.cgi?id=136501
     (5026766)	URL: http://www.ktxt.net
     (5026766)	Comments: http://bugzilla.mozilla.org/show_bug.cgi?id=136501
     (5026695)	URL: http://www.ktxt.net
     (5026695)	Comments: http://bugzilla.mozilla.org/show_bug.cgi?id=136501
     (5020266)	URL: http://www.ktxt.net/
     (5020266)	Comments: Just go there
     (5020221)	URL: http://www.ktxt.net
     (5020221)	Comments: testing crash in bug 136501

Comment 36

[Håkan Waara]

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

Comment 37

[Olivier Cahagne]

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

Comment 38

[R.K.Aa.]

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

Comment 39

[R.K.Aa.]

Is this fixed on the 1.0 branch too now?

Comment 40

[Matthias Versen [:Matti]]

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

Comment 41

[Matthias Versen [:Matti]]

This is not fixed on the branch. 
bug 143907 is crashing only with RC2 but not with the trunk

Comment 42

[John Morrison]

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

Comment 43

[John Morrison]

I think we should consider migrating this patch onto the mozilla1.0 branch,
and if it's too much for that, then Netscape should take this patch further
on.

Comment 44

[Matthias Versen [:Matti]]

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

Comment 45

[John Morrison]

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

Comment 46

[John Morrison]

verified fixed for all the HTML testcases and webpages noted in this bug.

(There is still a crash for fieldset/legend used in a XUL document, but that
is obscure to say the least. Filed bug 145853 to cover that issue separately).

Comment 47

[Phil Housley]

This crash is back on RC3 on win98SE.  The test case here will cause it every
time.  Someone test and reopen please.

Comment 48

[Håkan Waara]

Yes, attachment 78756 [details] crashes again.  Reopening and marking regression.

Comment 49

[Håkan Waara]

Oops, this fix is apparently not checked in to the 1.0 branch (why not!?), so
it's no regression.  Sorry for the noise all!

Comment 50

[Håkan Waara]

Once again, verified.

Comment 51

[Michael Lefevre]

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

Comment 52

[John Morrison]

reopening to gift onto waterson

I don't see any reason that this shouldn't be landed on a branch (or two).

Comment 53

[John Morrison]

-> waterson

This is the #40 topcrash on mozilla 1.0RC3. This has baked on the trunk 
since 4/18 (6 weeks), and the crash is not visible on the trunk talkback 
data.

I don't know if this is visible specifically on top100 sites, but it would
be very simple for a change in design to introduce this crash at such a site
(i.e., the HTML/CSS required to crash the browser is entirely legal, and not
uncommon). 

Comment 54

[John Morrison]

marking fixed again.

Comment 55

[John Morrison]

marking verified again.

Comment 56

[Jaime Rodriguez, Jr.]

adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending
Drivers approval. 

Comment 57

[John Morrison]

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

Comment 58

[gabriel]

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

Comment 59

[Egbert Gerber]

are you sure bug 145533 is a duplicate of this one?
Mozilla 1.1a (build 2002061104) still crashes when accessing http://www.portevo.de/

Comment 60

[Adam Cooper]

I am still experiencing this bug. A visit to http://www.vbug.com causes the
following page fault

MOZILLA caused an invalid page fault in
module GKLAYOUT.DLL at 0167:603ef5ea.
Registers:
EAX=00000000 CS=0167 EIP=603ef5ea EFLGS=00010246
EBX=00000000 SS=016f ESP=0064df24 EBP=0064df3c
ECX=0064e09c DS=016f ESI=0064e014 FS=3477
EDX=00000000 ES=016f EDI=0064e338 GS=0000
Bytes at CS:EIP:
8b 50 04 89 51 10 8b 40 08 89 41 14 8b 44 24 08 
Stack dump:
603ed2c7 00000000 0064e034 0064e2f8 02192d6c 00000000 0064e1ec 603e6d09 0064e2f8
40000000 02192d6c 0064e3a8 00000000 0064e40c 02192d6c 02d06c30 

Comment 61

[Bas van Duijnhoven]

www.schaapskudde.nl
www.portevo.de
www.vbug.com
all wfm with 1.1 alpha (2002061104) on win 98

Comment 62

[John Morrison]

... and the above three sites mentioned crash in the current 1.0.1 branch 
builds. But that's to be expected since the fix for this crash has not been
landed on the branch but is targetted to be landed.

The FIXED status is for the trunk so returning to fixed state. (Yes, I find 
this confusing too, but what can I say).

Comment 63

[John Morrison]

verified for trunk. 

Comment 64

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 65

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to MOZILLA_1_0_BRANCH, 2002-06-20 20:25 PDT.

Comment 66

[Michael Lefevre]

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

Comment 67

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 68

[Chris Petersen]

Verified in the Windows Me (2002-07-16-080 and OSX (2002-07-16-05) branch builds.

Comment 69

[Wesha]

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

Comment 70

[R.K.Aa.]

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