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)
Core
Layout
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)
7.58 KB,
text/plain
|
Details | |
93 bytes,
text/html
|
Details | |
260 bytes,
text/html
|
Details | |
4.91 KB,
patch
|
alexsavulov
:
review+
waterson
:
superreview+
jud
:
approval+
|
Details | Diff | Splinter Review |
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•23 years ago
|
||
#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
Comment 2•23 years ago
|
||
This is happening on current trunk as well.
Comment 3•23 years ago
|
||
Comment 4•23 years ago
|
||
Testcase WFM with Mac OS 9.1 build 2002031106
Comment 5•23 years ago
|
||
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
Updated•23 years ago
|
Priority: -- → P2
Comment 6•23 years ago
|
||
#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•23 years ago
|
||
*** Bug 132823 has been marked as a duplicate of this bug. ***
Comment 8•23 years ago
|
||
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]
Comment 9•23 years ago
|
||
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
Assignee | ||
Comment 10•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
*** Bug 135368 has been marked as a duplicate of this bug. ***
Comment 13•23 years ago
|
||
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•23 years ago
|
||
Adding the url http://www.schaapskudde.nl from bug 77630.
Comment 15•23 years ago
|
||
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.
Assignee | ||
Comment 16•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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
Comment 19•23 years ago
|
||
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•23 years ago
|
||
Comment 21•23 years ago
|
||
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?
Comment 23•23 years ago
|
||
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•23 years ago
|
||
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.
Comment 26•23 years ago
|
||
good catch on the leak - thanks, I'll fix that.
Assignee | ||
Comment 27•23 years ago
|
||
Comment on attachment 78757 [details] [diff] [review]
revised patch to handle the incremental reflow as well
sr=waterson. looks great!
Attachment #78757 -
Flags: superreview+
Comment 28•23 years ago
|
||
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•23 years ago
|
||
OOPS! SORRY I POSTED THE STACK ON THE WRONG BUG!
DISREGARD PREVIOUS COMMENT! SORRY!
Comment 30•23 years ago
|
||
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+
Comment 31•23 years ago
|
||
*** Bug 137980 has been marked as a duplicate of this bug. ***
Comment 32•23 years ago
|
||
*** Bug 133272 has been marked as a duplicate of this bug. ***
Comment 33•23 years ago
|
||
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
Comment 34•23 years ago
|
||
*** Bug 136501 has been marked as a duplicate of this bug. ***
Comment 35•23 years ago
|
||
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]
Comment 36•23 years ago
|
||
*** Bug 138774 has been marked as a duplicate of this bug. ***
Comment 37•23 years ago
|
||
*** Bug 139414 has been marked as a duplicate of this bug. ***
Comment 38•23 years ago
|
||
*** Bug 143079 has been marked as a duplicate of this bug. ***
Comment 39•23 years ago
|
||
Is this fixed on the 1.0 branch too now?
Comment 40•23 years ago
|
||
*** Bug 143907 has been marked as a duplicate of this bug. ***
Comment 41•23 years ago
|
||
This is not fixed on the branch.
bug 143907 is crashing only with RC2 but not with the trunk
Comment 42•23 years ago
|
||
*** Bug 144670 has been marked as a duplicate of this bug. ***
Comment 43•23 years ago
|
||
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
Comment 44•23 years ago
|
||
*** Bug 145533 has been marked as a duplicate of this bug. ***
Comment 45•23 years ago
|
||
*** Bug 145793 has been marked as a duplicate of this bug. ***
Comment 46•23 years ago
|
||
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).
Status: RESOLVED → VERIFIED
Comment 47•23 years ago
|
||
This crash is back on RC3 on win98SE. The test case here will cause it every
time. Someone test and reopen please.
Comment 48•23 years ago
|
||
Yes, attachment 78756 [details] crashes again. Reopening and marking regression.
Comment 49•23 years ago
|
||
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 ago → 23 years ago
Keywords: regression
Resolution: --- → FIXED
Comment 51•23 years ago
|
||
*** Bug 147837 has been marked as a duplicate of this bug. ***
Comment 52•23 years ago
|
||
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 → ---
Comment 53•23 years ago
|
||
-> 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•23 years ago
|
||
marking fixed again.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Updated•23 years ago
|
Keywords: adt1.0.1,
mozilla1.0.1
Comment 56•23 years ago
|
||
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending
Drivers approval.
Comment 57•23 years ago
|
||
*** Bug 148242 has been marked as a duplicate of this bug. ***
Comment 58•23 years ago
|
||
*** Bug 148351 has been marked as a duplicate of this bug. ***
Comment 59•23 years ago
|
||
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•23 years ago
|
||
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 → ---
Comment 61•23 years ago
|
||
www.schaapskudde.nl
www.portevo.de
www.vbug.com
all wfm with 1.1 alpha (2002061104) on win 98
Comment 62•23 years ago
|
||
... 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 ago → 23 years ago
Keywords: mozilla1.0
Resolution: --- → FIXED
Updated•23 years ago
|
Attachment #78757 -
Flags: approval+
Comment 64•23 years ago
|
||
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+
Fix checked in to MOZILLA_1_0_BRANCH, 2002-06-20 20:25 PDT.
Keywords: mozilla1.0.1+ → fixed1.0.1
Comment 66•23 years ago
|
||
*** Bug 154362 has been marked as a duplicate of this bug. ***
*** Bug 152316 has been marked as a duplicate of this bug. ***
Comment 68•23 years ago
|
||
Verified in the Windows Me (2002-07-16-080 and OSX (2002-07-16-05) branch builds.
Keywords: verified1.0.1
Comment 69•22 years ago
|
||
*** Bug 164216 has been marked as a duplicate of this bug. ***
Comment 70•22 years ago
|
||
*** Bug 176180 has been marked as a duplicate of this bug. ***
Updated•14 years ago
|
Crash Signature: [@ nsBlockBandData::Init]
[@ nsSpaceManager::GetTranslation]
You need to log in
before you can comment on or make changes to this bug.
Description
•