Closed Bug 130251 Opened 23 years ago Closed 23 years ago

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

Categories

(Core :: Layout, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: robbusolin, Assigned: waterson)

References

()

Details

(Keywords: crash, regression, topcrash, Whiteboard: [adt2 RTM])

Crash Data

Attachments

(4 files, 2 obsolete files)

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>
#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
Assignee: asa → attinasi
Severity: normal → critical
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
Keywords: crash
OS: Windows 2000 → All
QA Contact: doronr → petersen
Hardware: PC → All
Attached file Full stack
This is happening on current trunk as well.
Testcase WFM with Mac OS 9.1 build 2002031106
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
Priority: -- → P2
#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.
*** Bug 132823 has been marked as a duplicate of this bug. ***
This crashes on one of the sample XUL docs on mozilla.org too (the doc includes an <html:fieldset>).
Summary: crash with the fieldset tag in the 0.9.9 version → crash with the fieldset tag [@ nsSpaceManager::GetTranslation]
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.
Status: NEW → ASSIGNED
Priority: P2 → P1
Target Milestone: --- → mozilla1.0
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?
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
Blocks: 135368
*** Bug 135368 has been marked as a duplicate of this bug. ***
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?
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.
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...
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.
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 ;)
Attachment #78638 - Attachment is obsolete: true
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...
Waterson pointed out the incremental reflow case, and sure enough, that needs the space manager set too, thus this patch.
Attachment #78684 - Attachment is obsolete: true
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?
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.
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 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.
good catch on the leak - thanks, I'll fix that.
Comment on attachment 78757 [details] [diff] [review] revised patch to handle the incremental reflow as well sr=waterson. looks great!
Attachment #78757 - Flags: superreview+
Blocks: 136501
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()
OOPS! SORRY I POSTED THE STACK ON THE WRONG BUG! DISREGARD PREVIOUS COMMENT! SORRY!
Comment on attachment 78757 [details] [diff] [review] revised patch to handle the incremental reflow as well r= alexsavulov (including the changes we spoke about)
Attachment #78757 - Flags: review+
*** Bug 137980 has been marked as a duplicate of this bug. ***
*** Bug 133272 has been marked as a duplicate of this bug. ***
Checked in to trunk: /cvsroot/mozilla/layout/html/base/src/nsBlockFrame.cpp,v <-- nsBlockFrame.cpp new revision: 3.501; previous revision: 3.500
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 136501 has been marked as a duplicate of this bug. ***
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 waterson@netscape.com 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
Keywords: topcrash
Summary: crash with the fieldset tag [@ nsSpaceManager::GetTranslation] → crash with the fieldset tag [@ nsBlockBandData::Init][@ nsSpaceManager::GetTranslation]
*** Bug 138774 has been marked as a duplicate of this bug. ***
*** Bug 139414 has been marked as a duplicate of this bug. ***
*** Bug 143079 has been marked as a duplicate of this bug. ***
Is this fixed on the 1.0 branch too now?
*** Bug 143907 has been marked as a duplicate of this bug. ***
This is not fixed on the branch. bug 143907 is crashing only with RC2 but not with the trunk
*** Bug 144670 has been marked as a duplicate of this bug. ***
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.
Keywords: mozilla1.0, nsbeta1
*** Bug 145533 has been marked as a duplicate of this bug. ***
*** Bug 145793 has been marked as a duplicate of this bug. ***
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).
This crash is back on RC3 on win98SE. The test case here will cause it every time. Someone test and reopen please.
Yes, attachment 78756 [details] crashes again. Reopening and marking regression.
Status: VERIFIED → REOPENED
Keywords: regression
Resolution: FIXED → ---
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!
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Keywords: regression
Resolution: --- → FIXED
Once again, verified.
Status: RESOLVED → VERIFIED
Keywords: regression
*** Bug 147837 has been marked as a duplicate of this bug. ***
reopening to gift onto waterson I don't see any reason that this shouldn't be landed on a branch (or two).
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
-> 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).
Assignee: attinasi → waterson
Status: REOPENED → NEW
Keywords: adt1.0.0
marking fixed again.
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
marking verified again.
Status: RESOLVED → VERIFIED
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending Drivers approval.
Whiteboard: [adt2 RTM]
*** Bug 148242 has been marked as a duplicate of this bug. ***
*** Bug 148351 has been marked as a duplicate of this bug. ***
are you sure bug 145533 is a duplicate of this one? Mozilla 1.1a (build 2002061104) still crashes when accessing http://www.portevo.de/
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
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
www.schaapskudde.nl www.portevo.de www.vbug.com all wfm with 1.1 alpha (2002061104) on win 98
... 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).
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Keywords: mozilla1.0
Resolution: --- → FIXED
verified for trunk.
Status: RESOLVED → VERIFIED
Attachment #78757 - Flags: approval+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.
Fix checked in to MOZILLA_1_0_BRANCH, 2002-06-20 20:25 PDT.
*** Bug 154362 has been marked as a duplicate of this bug. ***
*** Bug 152316 has been marked as a duplicate of this bug. ***
Verified in the Windows Me (2002-07-16-080 and OSX (2002-07-16-05) branch builds.
Keywords: verified1.0.1
*** Bug 164216 has been marked as a duplicate of this bug. ***
*** Bug 176180 has been marked as a duplicate of this bug. ***
Crash Signature: [@ nsBlockBandData::Init] [@ nsSpaceManager::GetTranslation]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: