crash opening mail compose [@ nsBindingManager::WalkRules]

VERIFIED FIXED in M18

Status

()

Core
Event Handling
P1
critical
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: Chris Waterson, Assigned: Nisheeth Ranjan)

Tracking

({crash, topcrash})

Trunk
crash, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3++][PDTP1][ETA - 9/26], crash signature)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
I crashed opening the mail compose window, stack trace below. Digging a little 
bit, here's what I think is happening.

In the event state manager's SetContentState() method, around

http://lxr.mozilla.org/mozilla/source/layout/events/src/nsEventStateManager.cpp#
2543

we're calling nsIDocument::ContentStateChanged(), and passing in elements that 
may not have their mDocument pointer set.

Down in the bowels of XBL, nsBindingManager::WalkRules(), we *assume* that each 
element has its mDocument member set, see

http://lxr.mozilla.org/mozilla/source/layout/xbl/src/nsBindingManager.cpp#783

I'm not sure if the right fix is to be more paranoid in XBL, or if it's to make 
the ESM not notify with elements that aren't in the document.

nsBindingManager::WalkRules(nsBindingManager * const 0x022115e4, nsIStyleSet * 
0x0344a3d0, int (nsISupports *, void *)* 0x01ad4be3 SheetHasStatefulStyle
(nsISupports *, void *), void * 0x0012f43c, nsIContent * 0x0350dc00) line 783 + 
10 bytes
StyleSetImpl::WalkRuleProcessors(StyleSetImpl * const 0x00000000, int 
(nsISupports *, void *)* 0x01ad4be3 SheetHasStatefulStyle(nsISupports *, void 
*), void * 0x00000001, nsIContent * 0x0350dc00) line 2012
StyleSetImpl::HasStateDependentStyle(StyleSetImpl * const 0x00b22e98 
{"screen"}, nsIPresContext * 0x035c8208, nsIContent * 0x0350dc00) line 1109
nsCSSFrameConstructor::ContentStatesChanged(nsCSSFrameConstructor * const 
0x0283b170, nsIPresContext * 0x00000000, nsIContent * 0x0350dc00, nsIContent * 
0x031152d4) line 9776 + 21 bytes
StyleSetImpl::ContentStatesChanged(StyleSetImpl * const 0x0344a3d0, 
nsIPresContext * 0x035c8208, nsIContent * 0x0350dc00, nsIContent * 0x031152d4) 
line 1183
PresShell::ContentStatesChanged(PresShell * const 0x029c4258, nsIDocument * 
0x02c56560, nsIContent * 0x0350dc00, nsIContent * 0x031152d4) line 3596
nsXULDocument::ContentStatesChanged(nsXULDocument * const 0x02c56560, 
nsIContent * 0x0350dc00, nsIContent * 0x031152d4) line 1604
nsEventStateManager::SetContentState(nsEventStateManager * const 0x0350dc00, 
nsIContent * 0x031152d4, int 46490976) line 2578
nsEventStateManager::GenerateMouseEnterExit(nsEventStateManager * const 
0x00000000, nsIPresContext * 0x035c8208, nsGUIEvent * 0x02b2e3c8) line 1523
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x03473f20, 
nsIPresContext * 0x035c8208, nsEvent * 0x0012fae8, nsIFrame * 0x0369af44, 
nsEventStatus * 0x0012faa8, nsIView * 0x034710d0) line 306
PresShell::HandleEventInternal(PresShell * const 0x00000000, nsEvent * 
0x0012fae8, nsIView * 0x034710d0, nsEventStatus * 0x0012faa8) line 4228
PresShell::HandleEvent(PresShell * const 0x029c4250, nsIView * 0x034710d0, 
nsGUIEvent * 0x0012fae8, nsEventStatus * 0x0012faa8, int 0, int & 1) line 4166 
+ 15 bytes
nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x0012fae8, 
unsigned int 8, nsEventStatus * 0x0012faa8, int 0, int & 1) line 379
nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x034710d0, 
unsigned int 8, nsEventStatus * 0x0012faa8, int 0, int & 1) line 352
nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x0338e098, 
unsigned int 8, nsEventStatus * 0x0012faa8, int 0, int & 1) line 352
nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x0367b588, 
unsigned int 8, nsEventStatus * 0x0012faa8, int 0, int & 1) line 352
nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x0330e6f8, 
unsigned int 28, nsEventStatus * 0x0012faa8, int 1, int & 1) line 352
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x00001383, nsGUIEvent * 
0x0000000d, nsEventStatus * 0x0012faa8) line 1429
HandleEvent(nsGUIEvent * 0x0360bba8) line 68
nsWindow::DispatchEvent(nsWindow * const 0x0367b6e4, nsGUIEvent * 0x0012fae8, 
nsEventStatus & nsEventStatus_eIgnore) line 614 + 6 bytes
nsWindow::DispatchWindowEvent(nsWindow * const 0x00000000, nsGUIEvent * 
0x00000000) line 635
nsWindow::DispatchMouseEvent(nsWindow * const 0x00000000, unsigned int 300, 
nsPoint * 0x05f91002 {x=??? y=???}) line 3813
ChildWindow::DispatchMouseEvent(ChildWindow * const 0x00000000, unsigned int 
300, nsPoint * 0x00000000 {x=??? y=???}) line 4020 + 15 bytes
nsWindow::ProcessMessage(nsWindow * const 0x00000000, unsigned int 512, 
unsigned int 0, long 852301, long * 0x0012fcf0) line 2910
nsWindow::WindowProc(HWND__ * 0x003b0114, unsigned int 512, unsigned int 0, 
long 0) line 883 + 18 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
nsAppShellService::Run(nsAppShellService * const 0x00aa0fb8) line 408
main1(int 1, char * * 0x00372758, nsISupports * 0x003727a8) line 958 + 9 bytes
main(int 1, char * * 0x00372758) line 1139 + 25 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00400000, char * 0x00133a84, 
HINSTANCE__ * 0x00400000) line 1157 + 21 bytes
MOZILLA! WinMainCRTStartup + 308 bytes
KERNEL3
(Reporter)

Updated

17 years ago
Keywords: crash, nsbeta3

Comment 1

17 years ago
This is mine.
Assignee: joki → hyatt

Comment 2

17 years ago
nsbeta3+, but P2 until we know how often this actually happens.
Priority: P3 → P2
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18

Comment 3

17 years ago
*** Bug 53280 has been marked as a duplicate of this bug. ***

Comment 4

17 years ago
*** Bug 53280 has been marked as a duplicate of this bug. ***

Comment 5

17 years ago
This is joki's.  He's doing a notification for :hover on an element that isn't 
in the document.
Assignee: hyatt → joki

Comment 6

17 years ago
Changing Severity to Critical because several of us in the mail group crash 
daily bringing up the Compose window.  Suresh and Suzanne usually crash bringing 
up the Compose window the 2nd or 3rd time with in the same session (they have 
NT4 systems).  I crash on my Win98 system on the 4th or 5th crash and Jason 
crashes around the 6th time with win2000.   Can this be bumped to a P1 please?
Severity: normal → critical

Comment 7

17 years ago
joki, I think you just need to ensure that out of notifyContent[0], oldHover, 
and newHover, that you don't put one of those elements into the notifyContent 
array if it doesn't have a document.

Updated

17 years ago
Blocks: 53358

Comment 8

17 years ago
PDT agrees P2 since not everyone is hitting this crash. If everyone was crashing
bringing up a compose window, it would be P1.
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP2]

Comment 9

17 years ago
I agree with hyatt's solution.  I'll have it ready momementarily.
Status: NEW → ASSIGNED

Comment 10

17 years ago
*** Bug 53660 has been marked as a duplicate of this bug. ***
Adding topcrash keyword since this shows up prominently in talkback data.  Also
changing PC/Win2000 to All/All since some of the talkback reports are for Linux.
Keywords: topcrash
OS: Windows 2000 → All
Hardware: PC → All

Comment 12

17 years ago
Created attachment 15319 [details] [diff] [review]
Proposed patch

Comment 13

17 years ago
This patch fixes another instance of this stack trace with rods sent me.  I 
still can't reproduce this one myself but I'm trying to get hyatt to verify the 
fix for the mail part now.  If it works then this should go in.

Comment 14

17 years ago
We (suresh, esther, suzanne, ninoschka) are seeing this everyday with builds on 
9/20 and 9/21.  We're using Seamonkey for our daily use.  We crash around the 
3rd or 4th compose, reply or forward of a message.  The simple case of just 
opening and closing the compose window crashes less frequently, but daily use of 
mail is very frustrating with this crash.  Please raise the P2 to a P1.  

Comment 15

17 years ago
*** Bug 53748 has been marked as a duplicate of this bug. ***

Comment 16

17 years ago
joki, I was pretty consistently crashing while using mail compose this morning.  
After appyling your patch it has stopped. So it seems to be the right fix.  I'll 
update the bug if I see a crash.

Comment 17

17 years ago
adding [@ nsBindingManager::WalkRules] for topcrash tracking.  let me know if 
you need any info from talkback.
Summary: crash opening mail compose → crash opening mail compose [@ nsBindingManager::WalkRules]

Comment 18

17 years ago
marking nsbeta3++, P1
Priority: P2 → P1
Whiteboard: [nsbeta3+][PDTP2] → [nsbeta3++][PDTP2]

Comment 19

17 years ago
PDT:  upgrading to PDTP1 as intended earlier.
Whiteboard: [nsbeta3++][PDTP2] → [nsbeta3++][PDTP1]

Comment 20

17 years ago
Folks, are we going to check this patch in? This bug is killing me.

Comment 21

17 years ago
Updating QA Contact.
QA Contact: janc → lorca

Comment 22

17 years ago
I was gone over the weekend.  I'll try to get it in today.

Comment 23

17 years ago
Created attachment 15491 [details] [diff] [review]
diff -u from branch tree

Comment 24

17 years ago
So the patch checks to see if the old or new element which we're were/are 
hovering over is still in the doc.  If it is not we do not involve the node in 
any :hover checking/updating.

Comment 25

17 years ago
*** Bug 54138 has been marked as a duplicate of this bug. ***

Comment 26

17 years ago
*** Bug 54196 has been marked as a duplicate of this bug. ***

Comment 27

17 years ago
*** Bug 54196 has been marked as a duplicate of this bug. ***
*** Bug 54202 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

17 years ago
Assignee: joki → nisheeth
Status: ASSIGNED → NEW
Whiteboard: [nsbeta3++][PDTP1] → [nsbeta3++][PDTP1][ETA - 9/26]
(Assignee)

Comment 29

17 years ago
Re-assigning to myself.  I'll check in this patch into the branch and trunk
today because Tom is away on an DOM face to face meeting today and tomorrow.

Comment 30

17 years ago
*** Bug 54240 has been marked as a duplicate of this bug. ***

Comment 31

17 years ago
Nisheeth, Can you check in joki's fix into the tree today? Looks like both the 
trees are open now!!  Thanks!!

Comment 32

17 years ago
add scott and myself to cc list - want to verify this fixes another site with a
similar stack trace.

Comment 33

17 years ago
*** Bug 48371 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 34

17 years ago
Checked in joki's patch into the branch.
Status: NEW → ASSIGNED

Comment 35

17 years ago
Please also check it into the truck ASAP.

Comment 36

17 years ago
*** Bug 53969 has been marked as a duplicate of this bug. ***

Comment 37

17 years ago
is this in the trunk yet?
(Assignee)

Comment 38

17 years ago
Checked into the trunk.  Marking bug fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 39

17 years ago
Seems to me this bug is intermittent-I'll wait for the mail folks to let me know?  
Or does anyone have any guaranteed steps to reproduce this bug?  Waiting for 
help.  Thanks.

Comment 40

17 years ago
Yes, try going to www.ex-mozilla.org and click on the link that allows you to
edit entries - yesterday, it would crash in WalkRules; with the fix, it doesn't.

Comment 41

17 years ago
Yes, try going to www.ex-mozilla.org and click on the link that allows you to
edit entries - yesterday, it would crash in WalkRules; with the fix, it doesn't.

Comment 42

17 years ago
Mail news qa testing is OK with New Msg now using branch builds 2000-09-27 on
win98, mac and linux.  We don't crash anymore bringing up compose window many
times (at least 15) in one session.   This can be verified for New Msg window

Comment 43

17 years ago
*** Bug 54420 has been marked as a duplicate of this bug. ***

Comment 44

17 years ago
Created attachment 15742 [details]
stack trace I got verifying dupe 53969

Comment 45

17 years ago
I tried to verify that bug 53969 is really fixed. I went to bug 53969 selected 
print. Printed to an ps file. After the print dialog vanished, I moved the mouse 
over the textfields ( as pointed by karnaze) and got repeatable the stack trace 
under Win98. I made the CVS around 17 CET. Adding me to CC.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 46

17 years ago
I also got this stack trace printing two different bug reports.  It seems fixed
for mail compose but not fixed for all situations. The bug reports actually
printed, but the crashes did occur.
(Assignee)

Comment 47

17 years ago
Closing this bug because this bug is fixed.  If the printing bug is not fixed
then it was wrongly marked a duplicate of this one and should be re-opened.  I
will do that next.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Assignee)

Comment 48

17 years ago
Marking verified based on QA comments above.
Status: RESOLVED → VERIFIED

Comment 49

17 years ago
*** Bug 54847 has been marked as a duplicate of this bug. ***

Comment 50

17 years ago
*** Bug 53642 has been marked as a duplicate of this bug. ***
Crash Signature: [@ nsBindingManager::WalkRules]
You need to log in before you can comment on or make changes to this bug.