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)

x86
Windows 2000
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 115919
mozilla0.9.9

People

(Reporter: sspitzer, Assigned: hyatt)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(2 files)

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

Created:
Updated:
Size: