196012 - crash while hovering over menu - Trunk M130 [@ nsEventStateManager::DispatchMouseEvent] [@ 0x00000960 | 0x00000780 | 0x00000000]

Status: VERIFIED FIXED

(Core :: DOM: Events, defect, P1)

Description

[Adam Hauner]

Mozilla 1.3 branch build and also trunk build are crashing on attached testcase.

Repro:
1. open testcase
2. point mouse over first item in main menu
3. after submenu appear, move mouse on it
4. move mouse back to main menu
5. repeat points 2 to 5 until crash

1.3 latest branch build:
TB17749790W
TB17749976G
TB17750023Y

2003030408 trunk build:
TB17749437M
TB17749442M
TB17749455W
TB17749474X
TB17749576Z
TB17749598K
TB17749607H

Comment 1

[Adam Hauner]

Attachment: CSS styles for testcase

Comment 2

[Adam Hauner]

Attachment: JS for testcase

Comment 3

[Adam Hauner]

Attachment: Testcase

Comment 4

[Adam Hauner]

-> Layout

Comment 5

[Olivier Cahagne]

just to make sure someone else also reproduced the crash, I crashed Mozilla
2003030408 on Win2k using the testcase.

Comment 6

[Adam Hauner]

It's regression between 2003021908/trunk (not crashing) and 2003022008/trunk
build (crashing -> TB17755730K, TB17755715M).

Comment 7

[joakim_46]

WFM with build 2003021008 under Windows XP SP1.

Comment 8

[dsirnapalli]

Able to crash it on 20030305(1.3b) mozilla nightly trunk build on Windows XP.

Comment 9

[Jay Patel [:jay]]

Looks a lot like bug 186132 and bug 194493.  I guess this bug is still not
entirely fixed.  

Cc'ing [e-mail]

Here is a recent incident submitted:
Incident ID 17755715
Stack Signature 	nsEventStateManager::DispatchMouseEvent f7f363c4
Email Address 	[e-mail]
Product ID 	MozillaTrunk
Build ID 	2003022008
Trigger Time 	2003-03-05 06:18:58
Platform 	Win32
Operating System 	Windows NT 5.0 build 2195
Module 	gklayout.dll
URL visited 	
User Comments 	
Trigger Reason 	Access violation
Source File Name 
c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp
Trigger Line No. 	2447
Stack Trace 	
nsEventStateManager::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 2447]
nsEventStateManager::GenerateMouseEnterExit
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 2530]
nsEventStateManager::PreHandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 376]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6225]
PresShell::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6181]
nsViewManager::HandleEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2212]
nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 304]
nsViewManager::DispatchEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 1948]
HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 83]
nsWindow::DispatchEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1120]
nsWindow::DispatchWindowEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1137]
nsWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5385]
ChildWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5640]
nsWindow::ProcessMessage
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 4069]
nsWindow::WindowProc
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1404]
USER32.dll + 0x2a244 (0x77e3a244)
USER32.dll + 0x45e5 (0x77e145e5)
USER32.dll + 0xa792 (0x77e1a792)
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 480]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1289]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1639]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1660]
WinMainCRTStartup()
KERNEL32.dll + 0x2847c (0x77ea847c) 

Comment 10

[John Keiser (jkeiser)]

I would like to note that while this shows up as a topcrash due to there being
11 reports, every single one of the reports was generated by [e-mail]. 
There were no reports from builds between the 26th and the 4th, either due to
difficulty reproducing or the problem not appearing.

Nonetheless, I can reproduce with this testcase and I'm looking at it.  This
appears to be happening due to ClearFrameRefs() not being called at all in this
case ... probably the bit is not being set.

Comment 11

[Andrew Schultz]

testcase also crashes linux trunk build 20030305

==> DOM Events

Comment 12

[Adam Hauner]

John Keiser: I'm sorry to generate topcrash, but I'm actually designing website
containing this kind of menu. I also tryed different nightbuilds to track begin
of regression.

Comment 13

[John Keiser (jkeiser)]

Don't get me wrong, I'm happy for many reports, I just wanted to point out that
this may not be as topcrashy as it seems.  Still worth checking in if I can
figure out the cause before 1.3.

Comment 14

[Adam Hauner]

Attachment: Simplified testcase

Comment 15

[John Keiser (jkeiser)]

oh, this is clearly mine

Comment 16

[Jay Patel [:jay]]

Adding [@ 0x00000960 | 0x00000780] to summary since there have been quite a few
crashes like this being reported under those stack signatures as well on the
MozillaTrunk.

Comment 17

[Adam Hauner]

Moving to Trunk as M1.3 released.

Comment 18

[Jay Patel [:jay]]

Since we already have a reproducible testcase I'm not going to add anymore
Talkback data to this bug.  Just wanted to note that we are still seeing these
crashes on the MozillaTrunk and that we should get a Target Milestone set for
the bug.

Comment 19

[Adam Hauner]

Attachment: More simplified testcase

Comment 20

[Jay Patel [:jay]]

Adding 0x00000000 to summary since Adam just crashed under that stack signature
as well.

Comment 21

[John Keiser (jkeiser)]

Attachment: Patch

Oops, lost track of this.  This fixes the problem: the frame may change during
the DispatchMouseEvent method, and if it does and we are holding onto an
external reference to it, we need to ensure that the FRAME_EXTERNAL_REFERENCE
bit is set on the new frame.

I begin to wonder if we should not just stop caching targeted frames and
re-determine where they are.  There are too many ClearFrameRef-related crashes
every time we try to change something.

Comment 22

[Greg K.]

Reproduced using FizzillaMach/2003-05-01-08-trunk, crashing in "0x74c" after
nsEventStateManager::GenerateMouseEnterExit. Setting Hardware=All.

Comment 23

[Greg K.]

Attachment: Crash report generated by FizzillaMach/2003-05-01-08-trunk showing crash at 0x74c after nsEventStateManager::GenerateMouseEnterExit

Comment 24

[Andreas Kunz]

Ummm... this is blocking1.4b+, but is awaiting review for already 10 days.
Maybe...

Comment 25

[Peter Lubczynski]

Comment on attachment 121608 [details] [diff] [review]
Patch

r=peterl

Comment 26

[Asa Dotzler [:asa]]

Comment on attachment 121608 [details] [diff] [review]
Patch

a=asa (on behalf of drivers) for checkin to 1.4b.

Comment 27

[John Keiser (jkeiser)]

Fix checked in.

Comment 28

[Adam Hauner]

I just tested all testcases wit 2003050610/trunk/W2K and Mozilla didn't crash.
Could anybody verify this bug on Linux?

Comment 29

[Patrick]

Test cases from comment 14 and comment 19 don't crash my Moz 2003050622 on
Mandrake 9.1. Verifying/fixed for Linux.

Comment 30

[Karl Tomlinson (back Dec 8 :karlt)]

Attachment: null MediaInputPort::mGraph when removing port from graph

This shouldn't be necessary, if clients do the right things, but provides some
safety, in case they don't.

Comment 31

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Not sure if you noticed ... but I think you left a digit out of your bug # when you did bzexport.

Comment 32

[Karl Tomlinson (back Dec 8 :karlt)]

Comment on attachment 8462313 [details] [diff] [review]
null MediaInputPort::mGraph when removing port from graph

Ah, thanks Kyle.  196012 was the revision, but I've learned that bzexport treats a single argument as a bug number, not a revision.  (I didn't notice it actually succeeded after telling me about the bug number mismatch.)