Trunk and N7.0 both show limited numbers of this crash. I was able to reproduce the crash with the following steps (in N7.0): 1) Go to http://www.uww.edu/index4.html 2) Select File | Edit Page (Now in composer. If this is indeed a border padding issue size of the window may be significant, mine is a little larger than a quarter of the screen.) 3) Select File | Save as... 4) Save the file. 5) Crash. This is producing the same crash that SusieW saw earlier today trying to forward an email, cc'ing her. Incident #10363179 -------------------- Product ID Gecko1.0 Build ID 2002082310 Operating System Windows NT 5.0 build 2195 Stack Trace nsStyleContext::GetBorderPaddingFor [d:\builds\seamonkey\mozilla\content\base\src\nsStyleContext.cpp, line 364] nsFrame::CalcBorderPadding [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrame.cpp, line 514] nsComboboxControlFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\forms\src\nsComboboxControlFrame.cpp, line 1601] nsLineLayout::ReflowFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp, line 1070] nsBlockFrame::ReflowInlineFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3650] nsBlockFrame::DoReflowInlineFrames [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3524] nsBlockFrame::DoReflowInlineFramesAuto [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3449] nsBlockFrame::ReflowInlineFrames [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3394] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2507] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2190] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 893] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833] nsTableCellFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableCellFrame.cpp, line 949] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833] nsTableRowFrame::ReflowChildren [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 1039] nsTableRowFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowFrame.cpp, line 1457] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833] nsTableRowGroupFrame::ReflowChildren [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp, line 448] nsTableRowGroupFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableRowGroupFrame.cpp, line 1212] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833] nsTableFrame::ReflowChildren [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 3294] nsTableFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 2004] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833] 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 1613] nsBlockReflowContext::DoReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 571] nsBlockReflowContext::ReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 349] nsBlockFrame::ReflowBlockFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3151] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2412] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2190] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 893] nsBlockReflowContext::DoReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 571] nsBlockReflowContext::ReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 349] nsBlockFrame::ReflowBlockFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3151] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2412] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2190] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 893] nsBlockReflowContext::DoReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 571] nsBlockReflowContext::ReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 349] nsBlockFrame::ReflowBlockFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3151] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2412] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2190] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 893] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833] CanvasFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp, line 567] nsBoxToBlockAdaptor::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 887] nsBoxToBlockAdaptor::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 628] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1062] 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 1062] nsContainerBox::LayoutChildAt [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp, line 650] nsGfxScrollFrameInner::LayoutBox [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1082] nsGfxScrollFrameInner::Layout [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1241] nsGfxScrollFrame::DoLayout [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1090] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1062] nsBoxFrame::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 1001] nsGfxScrollFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 780] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 833] ViewportFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 603] IncrementalReflow::Dispatch [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 893] PresShell::ProcessReflowCommands [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6482] ReflowEvent::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6330] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 597] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 530]

-> Kin

also get this with linux trunk build 20020929

the stack is different, but is still in the stylesystem. (gdb) frame 6 #6 nsCachedStyleData::GetStyleData (this=0x8af21d4, aSID=@0xbfffd774) at ../../../dist/include/content/nsRuleNode.h:218 218 data = *NS_REINTERPRET_CAST(nsStyleStruct**, dataSlot); (gdb) info locals dataSlot = 0xfffffffc <Address 0xfffffffc out of bounds> aSID = (nsStyleStructID &) @0xfffffffc: Cannot access memory at address 0xfffffffc (gdb) frame 7 #7 0x40d9f72c in nsRuleNode::GetStyleData (this=0x8af21c4, aSID=eStyleStruct_Border, aContext=0x8af21f0, aComputeData=1) at nsRuleNode.cpp:4709 4709 const nsStyleStruct* cachedData = mStyleData.GetStyleData(aSID); (gdb) p mStyleData $11 = {static gInfo = 0x40e2ca60, mInheritedData = 0xdddddddd, mResetData = 0xdddddddd} (gdb) p aSID $12 = eStyleStruct_Border

In the debugger, it looks like the mStyleContext for the combobox block frame has destroyed data in it. I'm wondering if this is related some how to bug 123049, though that bug has an entirely different stack trace.

Ok it looks like we crash because the combobox frame's anonymous child block frame, which strangely has a text node as it's mContent, is never really removed by a call to |ContentRemoved()| because there is code in |ContentRemoved()| that throws an error if you are removing a child of a combobox frame. nsCSSFrameConstructor::ContentRemoved() line 9617 nsCSSFrameConstructor::RecreateFramesForContent() line 12017 + 35 bytes nsCSSFrameConstructor::ProcessRestyledFrames() line 10262 PresShell::ReconstructStyleData() line 5522 PresShell::StyleSheetRemoved() line 5559 nsDocument::RemoveStyleSheet() line 1565 nsStyleLinkElement::UpdateStyleSheet() line 207 nsHTMLLinkElement::SetAttr() line 150 nsGenericHTMLElement::SetAttr() line 1751 + 36 bytes nsHTMLLinkElement::SetAttr() line 155 + 21 bytes nsDOMAttribute::SetValue() line 150 + 36 bytes nsDOMAttribute::SetNodeValue() line 218 nsWebBrowserPersist::FixupNodeAttribute() line 2882 nsWebBrowserPersist::CloneNodeWithFixedUpURIAttributes() line 2673 + 22 bytes nsEncoderNodeFixup::FixupNode() line 3275 + 19 bytes nsDocumentEncoder::SerializeNodeStart() line 300 + 66 bytes nsDocumentEncoder::SerializeToStringRecursive() line 381 + 20 bytes nsDocumentEncoder::SerializeToStringRecursive() line 402 + 21 bytes nsDocumentEncoder::SerializeToStringRecursive() line 402 + 21 bytes nsDocumentEncoder::SerializeToStringRecursive() line 402 + 21 bytes nsDocumentEncoder::EncodeToString() line 954 + 21 bytes nsDocumentEncoder::EncodeToStream() line 994 + 19 bytes nsWebBrowserPersist::SaveDocumentWithFixup() line 3076 + 44 bytes nsWebBrowserPersist::SaveDocuments() line 1521 + 87 bytes nsWebBrowserPersist::OnStopRequest() line 664 + 11 bytes nsFileChannel::OnStopRequest() line 595 nsOnStopRequestEvent::HandleEvent() line 213 nsARequestObserverEvent::HandlePLEvent() line 116 PL_HandleEvent() line 646 + 10 bytes PL_ProcessPendingEvents() line 576 + 9 bytes nsEventQueueImpl::ProcessPendingEvents() line 388 + 12 bytes nsWindow::DispatchPendingEvents() line 3609 nsWindow::ProcessMessage() line 3844 nsWindow::WindowProc() line 1308 + 27 bytes USER32! 77e11b60() USER32! 77e11cca() USER32! 77e183f1() nsAppShellService::Run() line 472 main1() line 1522 + 32 bytes main() line 1883 + 37 bytes mainCRTStartup() line 338 + 17 bytes This leaves frames in the frame tree, with mStyleContexts that point to mRuleNodes that get blown away when the stack unwinds back to |ReconstructStyleData()|: nsRuleNode::~nsRuleNode line 447 nsRuleNode::`scalar deleting destructor' + 15 bytes nsRuleNode::Destroy line 415 nsRuleList::~nsRuleList line 73 nsRuleList::`scalar deleting destructor' + 15 bytes nsRuleList::Destroy line 87 nsRuleList::~nsRuleList line 75 nsRuleList::`scalar deleting destructor' + 15 bytes nsRuleList::Destroy line 87 nsRuleList::~nsRuleList line 75 nsRuleList::`scalar deleting destructor' + 15 bytes nsRuleList::Destroy line 87 nsRuleList::~nsRuleList line 75 nsRuleList::`scalar deleting destructor' + 15 bytes nsRuleList::Destroy line 87 nsRuleNode::~nsRuleNode line 456 nsRuleNode::`scalar deleting destructor' + 15 bytes nsRuleNode::Destroy line 415 StyleSetImpl::EndRuleTreeReconstruct line 1325 PresShell::ReconstructStyleData line 5531 PresShell::StyleSheetRemoved line 5559 nsDocument::RemoveStyleSheet line 1565 nsStyleLinkElement::UpdateStyleSheet line 207 nsHTMLLinkElement::SetAttr line 150 nsGenericHTMLElement::SetAttr line 1751 + 36 bytes nsHTMLLinkElement::SetAttr line 155 + 21 bytes nsDOMAttribute::SetValue line 150 + 36 bytes nsDOMAttribute::SetNodeValue line 218 nsWebBrowserPersist::FixupNodeAttribute line 2882 nsWebBrowserPersist::CloneNodeWithFixedUpURIAttributes line 2673 + 22 bytes nsEncoderNodeFixup::FixupNode line 3275 + 19 bytes nsDocumentEncoder::SerializeNodeStart line 300 + 66 bytes nsDocumentEncoder::SerializeToStringRecursive line 381 + 20 bytes nsDocumentEncoder::SerializeToStringRecursive line 402 + 21 bytes nsDocumentEncoder::SerializeToStringRecursive line 402 + 21 bytes nsDocumentEncoder::SerializeToStringRecursive line 402 + 21 bytes nsDocumentEncoder::EncodeToString line 954 + 21 bytes nsDocumentEncoder::EncodeToStream line 994 + 19 bytes nsWebBrowserPersist::SaveDocumentWithFixup line 3076 + 44 bytes nsWebBrowserPersist::SaveDocuments line 1521 + 87 bytes nsWebBrowserPersist::OnStopRequest line 664 + 11 bytes nsFileChannel::OnStopRequest line 595 nsOnStopRequestEvent::HandleEvent line 213 nsARequestObserverEvent::HandlePLEvent line 116 PL_HandleEvent line 646 + 10 bytes PL_ProcessPendingEvents line 576 + 9 bytes nsEventQueueImpl::ProcessPendingEvents line 388 + 12 bytes nsWindow::DispatchPendingEvents line 3609 nsWindow::ProcessMessage line 3844 nsWindow::WindowProc line 1308 + 27 bytes USER32! 77e11b60 USER32! 77e11cca USER32! 77e183f1 nsAppShellService::Run line 472 main1 line 1522 + 32 bytes main line 1883 + 37 bytes mainCRTStartup line 338 + 17 bytes Another interesting tidbit, is that a strategically placed breakpoint at the point where we create the combobox frame's anonymous child block frame can adjust timing so that both the combobox frame and the child block frame have the same styleContexts ... and instead of the anonymous child block frame ending up in the change list in |ReconstructStyleData()|, the combobox frame itself ends up in the change list, and everything works just fine. This is sort of similar to what I was seeing when trying to create the test case attatched to the bug. Sometimes things worked, but most of the times things crashed. Another thing I should mention, is that I know when this bug will occur because I see this warning message twice in the console: frame: Block(-1) (039BDA40) style: 039BDABC :-moz-display-comboboxcontrol-frame {} Wrong parent style context: style: 039BD32C {} should be using: style: 039C06A0 {} I don't see it in the console when things work fine.

Yet another reason why we need XBL form controls as soon as possible.

i have spent more than one week on this. really made some progresses but still not find its root. kin is right. an error occured in nsCSSFrameConstructor::ContentRemoved() line 9617 at this point, it is reconstructing a stylechanged Frame which is nsComboboxControl::mDisplayFrame. pls read PresShell::ReconstructStyleData(...) { ... <A> FrameManager::ComputeStyleChangeFor(...aChangeList...) .... <B> FrameManager::ProcessReStyledFrames(...aChangeList...) .... } that frame is added to aChangeList in <A>, indicating its style has changed (because new stylesheet was added). so in <B>, we try to reconstruct the frame and get a error in ContentRemoved. the point is the Frame should not be added to aChangeList at all since no style change for it. Deep in why it is added( i.e find what change between its old stylecontext and new resolved sytlecontext), i find that the new stylecontext for the frame has a wrong nsStyleUserInput data which is NS_STYLE_USER_INPUT_AUTO instead of NS_STYLE_USER_INPUT_NONE. (note that the frame, nsComboboxControlFrame::mDisplayFrame is nsBlockFrame which is parent of mTextFrame which is used to display combobox's content ) This new styleContext is created at: FrameManager::ReResolveStyleContext { ... +1741 aPresContext->ResovePseudoStyleContextForNonElement(...) ... } i have tried my best to clarify what i have get :) i really hope what i said can be understood. :) if u can or can't, tell me please. it will be very appreciated if some CSS guy can give some hints. --> take it

(Another thought: why are we adding and removing stylesheets in order to serialize a document? It shouldn't crash when we do, but why bother?)

y. i wondered why we do it also when i began.i don't know much about it so assumed it should be ok. Even we shouldn'd add/remove when serializing a document, finding the root why it crash here is still needed.

> (Another thought: why are we adding and removing stylesheets in order to > serialize a document? It shouldn't crash when we do, but why bother?) Comment #7 illustrates what's happening ... the document encoder is replacing the url to the stylesheet on the net, with a url to the local saved version.

But why does the document need to be hooked up to a pres shell while that happens?

I guess it's because we're serializing directly off the set of dom nodes currently being edited and displayed on screen. Are you suggesting that we blow away the presShell/frames just for a save, and then recreate them when we are done? I think the only modifications the encoder makes is mapping urls used in the doc to local urls. ---- Rick, have you tried tracking down the timing issue I pointed out in comment #7? I thought it was a bit strange that we don't end up with the same set of style contexts all the time, so there may be bug on the load side of things.

Sorry, I was thinking of webbrowserpersist saving, rather than editor saving (where you edit a remote URL and then save it locally).

> Are you suggesting that we blow away the presShell/frames just for a save Well.. if we have stylesheets in the doc we're doing that _anyway_, as we change the urls, right? Once per stylesheet.

---- >Rick, have you tried tracking down the timing issue I pointed out in comment #7? > >I thought it was a bit strange that we don't end up with the same set of style >contexts all the time, so there may be bug on the load side of things. yes, i really saw that happen, but very very seldomly, only once or twice . i think we maybe know more the strange thing if we find why we ResolvePesudoStyleContext a (nsBlockFrame*)mDisplayFrame which has a nsStyleUserInput ==NS_STYLE_USER_INPUT_AUTO instead of _NONE. another thing: this error( the frame has been added to aChangeList and frame-reconstructing failed in ContentRemoved, after this, the frame own a invalid RuleNode destroyed already) _has_ _happened_ when you click 'Edit Page' ! and is exposed when "Save As" or in other time.

very sorry, pls igore the last one #17, some typo in it ---- >Rick, have you tried tracking down the timing issue I pointed out in comment #7? > >I thought it was a bit strange that we don't end up with the same set of style >contexts all the time, so there may be bug on the load side of things. yes, i really saw that happen, but very very seldomly, only once or twice . i think we maybe know more about the strange thing if we find why we ResolvePesudoStyleContext a (nsBlockFrame*)mDisplayFrame which has a nsStyleUserInput==NS_STYLE_USER_INPUT_AUTO instead of _NONE. another thing: this error( the frame has been added to aChangeList and frame-reconstructing failed in ContentRemoved, after this, the frame own a invalid RuleNode destroyed already) _will_ _happen_ when you click 'Edit Page' ! and is exposed when "Save As" or in other time.

The patch in bug 197942 may fix this -- with that patch, the combobox itself and the anonymos block will have the same mContent, so an attempt to reframe it will reframe the whole combobox. I'll test for sure tonight.

I'm not seeing a crash with a current nightly..... (without my patch).

Is this still crashing now that bug 197942 is fixed?

bz: I also cannot reproduce it (1.6 on Win2k, URL and testcase tested), so you probably want to mark this fixed or WFM.

Yeah, marking so.