Closed Bug 116022 Opened 23 years ago Closed 23 years ago

[RR]crash when editing / deleting in a html message compose [@ nsStyleBorder::IsBorderSideVisible][@ FrameManager::ReResolveStyleContext][@ nsRuleNode::GetStyleData]

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 115919
Milestone:
mozilla0.9.9

People

(Reporter: sspitzer, Assigned: hyatt)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(2 files)

this mbox file contains the message that when you reply to it, and edit, you crash.
3.03 KB, text/plain
Details
a variant crash with steps to repro and a stack (non-debug)
5.01 KB, text/plain
Details
crash when editing / deleting in a html message compose oldColor is null. if(oldColor->mBackgroundImage.Length() > 0 && oldColor->mBackgroundImage != newColor->mBackgroundImage ){ FrameManager::ReResolveStyleContext(nsIPresContext * 0x06492100, nsIFrame * 0x05ad4544, nsIStyleContext * 0x058ece58, nsIContent * 0x06554670, int -1, nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 5, int & 0) line 1768 + 9 bytes FrameManager::ReResolveStyleContext(nsIPresContext * 0x06492100, nsIFrame * 0x058edad4, nsIStyleContext * 0x05ad6130, nsIContent * 0x0649ba20, int -1, nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 0, int & 0) line 1914 FrameManager::ReResolveStyleContext(nsIPresContext * 0x06492100, nsIFrame * 0x058ed0bc, nsIStyleContext * 0x05ad4330, nsIContent * 0x06492d30, int -1, nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 0, int & 0) line 1914 FrameManager::ReResolveStyleContext(nsIPresContext * 0x06492100, nsIFrame * 0x058ece8c, nsIStyleContext * 0x05b316c8, nsIContent * 0x06492d30, int -1, nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 0, int & 0) line 1914 FrameManager::ReResolveStyleContext(nsIPresContext * 0x06492100, nsIFrame * 0x0460f1a8, nsIStyleContext * 0x05b2ddd4, nsIContent * 0x06492d30, int -1, nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 0, int & 0) line 1914 FrameManager::ReResolveStyleContext(nsIPresContext * 0x06492100, nsIFrame * 0x0460f514, nsIStyleContext * 0x05b2dc7c, nsIContent * 0x06492d30, int -1, nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 0, int & 0) line 1914 FrameManager::ReResolveStyleContext(nsIPresContext * 0x06492100, nsIFrame * 0x0460f2b4, nsIStyleContext * 0x05b31730, nsIContent * 0x00000000, int -1, nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 0, int & 0) line 1914 FrameManager::ReResolveStyleContext(nsIPresContext * 0x06492100, nsIFrame * 0x0460f16c, nsIStyleContext * 0x00000000, nsIContent * 0x00000000, int -1, nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 0, int & 0) line 1914 FrameManager::ComputeStyleChangeFor(FrameManager * const 0x06498140, nsIPresContext * 0x06492100, nsIFrame * 0x0460f16c, int -1, nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 0, int & 0) line 2173 PresShell::ReconstructStyleData(PresShell * const 0x06498d50, int 0) line 5375 PresShell::StyleSheetAdded(PresShell * const 0x06498d58, nsIDocument * 0x06490bf0, nsIStyleSheet * 0x065d9560) line 5393 nsDocument::InsertStyleSheetAt(nsDocument * const 0x06490bf0, nsIStyleSheet * 0x065d9560, int 0, int 1) line 1399 CSSLoaderImpl::InsertSheetInDoc(nsICSSStyleSheet * 0x065d9560, int 0, nsIContent * 0x06556b20, int 1, nsICSSLoaderObserver * 0x00000000) line 1198 CSSLoaderImpl::LoadStyleLink(CSSLoaderImpl * const 0x06492ee0, nsIContent * 0x06556b20, nsIURI * 0x065d96c0, const nsString & {...}, const nsString & {...}, int -1, int 0, nsIParser * 0x00000000, int & 1, nsICSSLoaderObserver * 0x00000000) line 1458 + 26 bytes nsStyleLinkElement::UpdateStyleSheet(nsStyleLinkElement * const 0x06556b50, int 1, nsIDocument * 0x00000000, int -1) line 354 + 130 bytes nsHTMLLinkElement::SetDocument(nsHTMLLinkElement * const 0x06556b20, nsIDocument * 0x06490bf0, int 1, int 1) line 106 nsGenericHTMLContainerElement::InsertChildAt(nsGenericHTMLContainerElement * const 0x065d8ed0, nsIContent * 0x06556b20, int 0, int 1, int 1) line 3743 nsGenericElement::doInsertBefore(nsIDOMNode * 0x06556b44, nsIDOMNode * 0x06556c9c, nsIDOMNode * * 0x0012e8c4) line 2507 + 35 bytes nsGenericHTMLContainerElement::InsertBefore(nsGenericHTMLContainerElement * const 0x065d8ed0, nsIDOMNode * 0x06556b44, nsIDOMNode * 0x06556c9c, nsIDOMNode * * 0x0012e8c4) line 540 nsHTMLQuoteElement::InsertBefore(nsHTMLQuoteElement * const 0x065d8ef8, nsIDOMNode * 0x06556b44, nsIDOMNode * 0x06556c9c, nsIDOMNode * * 0x0012e8c4) line 60 + 27 bytes nsEditor::SplitNodeImpl(nsIDOMNode * 0x06554698, int 4, nsIDOMNode * 0x065d8ef8, nsIDOMNode * 0x0649ba54) line 2768 + 63 bytes SplitElementTxn::DoTransaction(SplitElementTxn * const 0x065d9e60) line 96 + 54 bytes nsTransactionItem::DoTransaction() line 181 + 18 bytes nsTransactionManager::BeginTransaction(nsITransaction * 0x065d9e60) line 1076 + 11 bytes nsTransactionManager::DoTransaction(nsTransactionManager * const 0x0649a590, nsITransaction * 0x065d9e60) line 137 + 18 bytes nsEditor::Do(nsEditor * const 0x064913a0, nsITransaction * 0x065d9e60) line 492 + 30 bytes nsEditor::SplitNode(nsEditor * const 0x064913a0, nsIDOMNode * 0x06554698, int 4, nsIDOMNode * * 0x0012ea8c) line 1250 + 16 bytes nsEditor::SplitNodeDeep(nsIDOMNode * 0x06554698, nsIDOMNode * 0x0649a2ac, int 89, int * 0x0012eb90, int 1, nsCOMPtr<nsIDOMNode> * 0x00000000, nsCOMPtr<nsIDOMNode> * 0x00000000) line 4201 + 52 bytes nsHTMLEditRules::WillInsertBreak(nsISelection * 0x064989a0, int * 0x0012ec94, int * 0x0012ecd4) line 1316 + 46 bytes nsHTMLEditRules::WillDoAction(nsHTMLEditRules * const 0x0649a3d4, nsISelection * 0x064989a0, nsRulesInfo * 0x0012ec98, int * 0x0012ec94, int * 0x0012ecd4) line 489 + 23 bytes nsPlaintextEditor::InsertLineBreak(nsPlaintextEditor * const 0x06491438) line 1018 + 56 bytes nsHTMLEditorLog::InsertLineBreak(nsHTMLEditorLog * const 0x06491438) line 193 + 9 bytes nsPlaintextEditor::TypedText(nsPlaintextEditor * const 0x064913a0, const nsAString & {...}, int 2) line 560 + 22 bytes nsHTMLEditor::TypedText(nsHTMLEditor * const 0x064913a0, const nsAString & {...}, int 2) line 1201 + 17 bytes nsHTMLEditor::HandleKeyPress(nsHTMLEditor * const 0x06491438, nsIDOMKeyEvent * 0x065d9f90) line 1164 + 33 bytes nsTextEditorKeyListener::KeyPress(nsTextEditorKeyListener * const 0x0649b690, nsIDOMEvent * 0x065d9f98) line 287 nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x06499960, nsIPresContext * 0x06492100, nsEvent * 0x0012f92c, nsIDOMEvent * * 0x0012f60c, nsIDOMEventTarget * 0x06490c24, unsigned int 2, nsEventStatus * 0x0012f89c) line 1633 + 41 bytes nsDocument::HandleDOMEvent(nsDocument * const 0x06490bf0, nsIPresContext * 0x06492100, nsEvent * 0x0012f92c, nsIDOMEvent * * 0x0012f60c, unsigned int 2, nsEventStatus * 0x0012f89c) line 3061 nsGenericElement::HandleDOMEvent(nsGenericElement * const 0x06492d30, nsIPresContext * 0x06492100, nsEvent * 0x0012f92c, nsIDOMEvent * * 0x0012f60c, unsigned int 1, nsEventStatus * 0x0012f89c) line 1897 + 39 bytes PresShell::HandleEventInternal(nsEvent * 0x0012f92c, nsIView * 0x064aed20, unsigned int 1, nsEventStatus * 0x0012f89c) line 6026 + 44 bytes PresShell::HandleEvent(PresShell * const 0x06498d54, nsIView * 0x064aed20, nsGUIEvent * 0x0012f92c, nsEventStatus * 0x0012f89c, int 0, int & 1) line 5951 + 25 bytes nsView::HandleEvent(nsView * const 0x064aed20, nsGUIEvent * 0x0012f92c, unsigned int 0, nsEventStatus * 0x0012f89c, int 0, int & 1) line 387 nsView::HandleEvent(nsView * const 0x064ad030, nsGUIEvent * 0x0012f92c, unsigned int 0, nsEventStatus * 0x0012f89c, int 0, int & 1) line 344 nsView::HandleEvent(nsView * const 0x064935a0, nsGUIEvent * 0x0012f92c, unsigned int 0, nsEventStatus * 0x0012f89c, int 1, int & 1) line 344 nsViewManager::DispatchEvent(nsViewManager * const 0x064939d0, nsGUIEvent * 0x0012f92c, nsEventStatus * 0x0012f89c) line 1921 HandleEvent(nsGUIEvent * 0x0012f92c) line 83 nsWindow::DispatchEvent(nsWindow * const 0x06493894, nsGUIEvent * 0x0012f92c, nsEventStatus & nsEventStatus_eIgnore) line 846 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f92c) line 867 nsWindow::DispatchKeyEvent(unsigned int 131, unsigned short 0, unsigned int 13) line 2528 + 15 bytes nsWindow::OnChar(unsigned int 13, unsigned int 13, unsigned char 1) line 2661 nsWindow::ProcessMessage(unsigned int 258, unsigned int 13, long 1835009, long * 0x0012fd24) line 3210 + 51 bytes nsWindow::WindowProc(HWND__ * 0x000e0228, unsigned int 258, unsigned int 13, long 1835009) line 1111 + 27 bytes USER32! 77e13eb0() USER32! 77e1401a() USER32! 77e192da() nsAppShellService::Run(nsAppShellService * const 0x00540640) line 303 main1(int 2, char * * 0x00484b90, nsISupports * 0x00000000) line 1264 + 32 bytes main(int 2, char * * 0x00484b90) line 1594 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e87903()
1) save this file under your "Local Folders" directory on disk. 2) start up mail, select this folder and select the message it contains. 3) reply 4) select the first 30 lines, and hit delete. I crash every time.
critical, I'm getting this with any message I reply to (and then edit.)
Severity: normal → critical
Shouldn't this go to the Style System / Layout component? I don't think anything changed lately in editor that could have caused this. Also, should this be made a blocker?
Keywords: crash
This is a very familiar crash location -- it's where we typically crash if we try to look at data that we've already destroyed in the reresolution process. This is likely to be related to hyatt's changes yesterday for bug 115787 and is likely also related to the issues in bug 105619 and bug 112696.
er, actually, |oldColor| is null? I'm more accustomed to it being a pointer to garbage...
Are you using HTML compose or plaintext compose?
er, never mind, I should read the summary. I just read the steps to reproduce...
Uhh, this is assigned to me, and is a crasher. My guess is it shouldn't be mine and from the comments here it looks like others are working on it. If you are working on it please take ownership, and if you think it should be mine please tell me.
This is mine.
Assignee: jfrancis → hyatt
Target Milestone: --- → mozilla0.9.8
I just looked at this in a debugger, and I believe you that it was null. I crashed in a different place, with the same problem -- GetStyleData returning null. I'm looking at a style context that has the following bits set: font, color, visibility, UI, SVG. It has structs in its mCachedStyleData for only visibility, font, color, text, UI, and SVG -- nothing wrong here (I'm just making notes in the bug as I look at it). It returned null for a border struct. So, looking at its rule node, the rule node has the following "inherit" bits: background, position, textreset, display, margin, padding, border, XUL. It has the following none bits: font, color, visibility, UI, SVG. Its mStyleData has neither an mInheritedData nor an mResetData. That seems wrong to me if the style context has just been asked for the border struct -- it has neither an "inherit" bit nor the struct. The rule node also looks like it has no rule, but it's a child of the root rule node, not the root rule node itself. That makes it look like the rule node is destroyed, maybe? (The style context has a refcount of 2 and a valid vtable pointer, so it doesn't seem like it's destroyed.)
ReconstructStyleData (on a StyleSheetAdded) should not be throwing away any rule nodes, so (assuming I didn't mess the function up somehow), no rule nodes should be deleted during re-resolution. I suspect that during ReResolve we simply aren't keeping the old style context tree in a sane state at every step of the re-resolution. As we start replacing old style contexts with new style contexts on frames, perhaps we're putting the old tree into a state where style data is missing.
I think both the rule node and its parent that I was looking at were just garbage -- their pres context pointers don't lead anywhere useful.
The parent of the style context in question and everything up the chain has a refcount of 1, not 2. This makes me think this piece of content is looking at a style context pointing at a rule tree that has since been destroyed.
The style context I'm looking at is the style context for an HR element that's inside a quote element that's inside the body element. I'm wondering if it's one of the generated-content frames for the HR (it's an nsInlineFrame).
Er, the frame parent is a quote element. The content parent of the HR is null.
The frame with the orphaned style context is an nsInlineFrame that is generated content (mState & 0x40 == 0x40). It's parent is an nsBlockFrame. I'm attempting to disable hyatt's FRAMECHANGE optimization to ReResolveStyleContext in nsFrameManager.cpp to see if that fixes the bug.
Nope -- that didn't fix the problem.
*** Bug 116336 has been marked as a duplicate of this bug. ***
*** Bug 116316 has been marked as a duplicate of this bug. ***
*** Bug 116370 has been marked as a duplicate of this bug. ***
*** Bug 116464 has been marked as a duplicate of this bug. ***
*** Bug 116465 has been marked as a duplicate of this bug. ***
Still occuring in build trunk <2001122108> on linux 2.4.17-rc2
Does NOT occur in 0.9.7 Release (BUILD <2001122108>)
*** Bug 116502 has been marked as a duplicate of this bug. ***
*** Bug 116507 has been marked as a duplicate of this bug. ***
I am now testing with build <2001122206> Just for information I cannot cause crash using <cr> in received text on compose window as I reported in bug 116465 for build <2001122008>
Keywords: topcrash
Summary: crash when editing / deleting in a html message compose → crash when editing / deleting in a html message compose [@ nsStyleBorder::IsBorderSideVisible][@ FrameManager::ReResolveStyleContext][@ nsRuleNode::GetStyleData]
QA Contact: sheelar → jrgm
Hmmm. Did we change the way we display the headers when doing a mail reply?
dbaron: That was bug 116044 which is now verified fixed.
*** Bug 117413 has been marked as a duplicate of this bug. ***
Summary: crash when editing / deleting in a html message compose [@ nsStyleBorder::IsBorderSideVisible][@ FrameManager::ReResolveStyleContext][@ nsRuleNode::GetStyleData] → [RR]crash when editing / deleting in a html message compose [@ nsStyleBorder::IsBorderSideVisible][@ FrameManager::ReResolveStyleContext][@ nsRuleNode::GetStyleData]
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.8 → mozilla0.9.9
This can't be reproduced anymore, and the things I saw when debugging this originally are exactly what would be fixed by the patch I'm about to attach to bug 115919. *** This bug has been marked as a duplicate of 115919 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
I don't know about Bug 115919, but this bug no longer seems to be a problem. Verified with a recent build on Win98.
This is back in build 2002012503.
Have you submitted a talkback report? How do you know it's the same bug?
I think I got a bit mixed up. Bug 116044 is back, and deleting the quoted header and then doing a few more deletes crashes it. Bug 116370 sounds like the same bug, but was marked a duplicate of this one, not bug 116022. I meant to comment in bug 116044, but it sounds like they have the same root cause... As Seth Spitzer said in bug 116044: > note, this may be related to #116022 > > which is the crash I get when trying to delete the extra header goop from the > reply body.
This bug is back alive as bug 141054, and I'm testing a fix.
v
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
Crash Signature: [@ nsStyleBorder::IsBorderSideVisible] [@ FrameManager::ReResolveStyleContext] [@ nsRuleNode::GetStyleData]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: