Closed Bug 185850 Opened 22 years ago Closed 22 years ago

Crash on http://wfrv_new.webtest.netnet.net/ [@ nsEventStateManager::DispatchMouseEvent ]

Categories

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

Product:
Core
Component:
DOM: Events
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.3beta

People

(Reporter: john, Assigned: john)

References

(
URL
)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

Patch
2.74 KB, patch
kmcclusk
: review+
roc
: superreview+
Details | Diff | Splinter Review 
http://wfrv_new.webtest.netnet.net/ is crashing in
nsEventStateManager::DispatchMouseEvent().  This is a regression due to bug 103055.
Blocks: 103055
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.3beta
Quick update: mCurrentTarget (the frame) appears to be invalid during the mouse
move event.  Either it's not getting cleared properly at the end of its natural
course, or the frame is getting destroyed during the mousemove event.
All right, the specific problem is that the frame goes away (for whatever
reason, probably setting style.background in this case) during the content
handling the event, and then when we try to dispatch to the frame we have
problems.  This would be a difficult situation if we had to consider split
frames like text nodes, but since we are only dispatching to elements we should
be able to just grab the primary frame again.

I need to investigate a bit further to figure out why this is a *new* problem.
just confirming crash with Linux debug build (CVS 20021217).

0x4136f296 in nsEventStateManager::DispatchMouseEvent (this=0x88e3d80, 
    aPresContext=0x874c480, aEvent=0xbfffef30, aMessage=331, 
    aTargetContent=0x894da38, aTargetFrame=0x899c360, 
    aRelatedContent=0x8950518) at nsEventStateManager.cpp:2413
2413	    aTargetFrame->HandleEvent(aPresContext, &event, &status);
[...]
OS: Windows XP → All
Hardware: PC → All
Summary: Crash on http://wfrv_new.webtest.netnet.net/ → Crash on http://wfrv_new.webtest.netnet.net/ [@ nsEventStateManager::DispatchMouseEvent ]
Attached patch Patch — — Splinter Review 
This fixes the problem.  Note that the problem is not perfectly consistent, at
least on my system; I have to mouseover the links for a while before I get it
to happen.
Attachment #109580 - Flags: review?(roc+moz)
Comment on attachment 109580 [details] [diff] [review]
Patch

r=kmcclusk@netscape.com
Attachment #109580 - Flags: review?(roc+moz) → review+
jkeiser, does this fix also fix the crasher problems in the recipient fields?

here's a stack:

0x00000000
nsEventStateManager::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 2416]
nsEventStateManager::GenerateMouseEnterExit
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 2518]
nsEventStateManager::PreHandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 377]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6150]
PresShell::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6078]
nsViewManager::HandleEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2209]
nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 304]
nsViewManager::DispatchEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 1949]
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 5378]
ChildWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5633]
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 + 0x27ad7 (0x77d67ad7)
USER32.dll + 0x2ccd4 (0x77d6ccd4)
USER32.dll + 0x4455 (0x77d44455)
USER32.dll + 0x95d5 (0x77d495d5)
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 472]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1559]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1907]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1927]
WinMainCRTStartup()
kernel32.dll + 0x214c7 (0x77e814c7) 




if not, I've logged bug #185928 on that msg compose crash.

if it is a dup, you can mark #185928 a dup of this bug.
Fix checked in
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 185928 has been marked as a duplicate of this bug. ***
Is this really fixed? I saw the following crash today. Mozilla CVS build on
linux. CVS sources were sync'd today.

(gdb) bt
#0  0x407045e1 in __libc_nanosleep () at __libc_nanosleep:-1
#1  0x40704461 in __sleep (seconds=300) at ../sysdeps/unix/sysv/linux/sleep.c:85
#2  0x0805f4c8 in ah_crap_handler (signum=11) at
/psolanki/mozilla/xpfe/bootstrap/nsSigHandlers.cpp:144
#3  0x4154d739 in nsProfileLock::FatalSignalHandler (signo=11, info=0xbfffe3d0,
context=0xbfffe450) at /psolanki/mozilla/profile/src/nsProfileAccess.cpp:1776
#4  0x4033ab53 in pthread_sighandler_rt (signo=11, si=0xbfffe3d0, uc=0xbfffe450)
at signals.c:121
#5  <signal handler called>
#6  0x40db7d3c in nsEventStateManager::DispatchMouseEvent (this=0x44927278,
aPresContext=0x461da330, aEvent=0xbfffeeb0, aMessage=332, 
    aTargetContent=0x4628f040, aTargetFrame=0x463d49e0,
aRelatedContent=0x46145020) at
/psolanki/mozilla/content/events/src/nsEventStateManager.cpp:2424
#7  0x40db8399 in nsEventStateManager::GenerateMouseEnterExit (this=0x44927278,
aPresContext=0x461da330, aEvent=0xbfffeeb0)
    at /psolanki/mozilla/content/events/src/nsEventStateManager.cpp:2526
#8  0x40dafa06 in nsEventStateManager::PreHandleEvent (this=0x44927278,
aPresContext=0x461da330, aEvent=0xbfffeeb0, aTargetFrame=0x4615c7a4, 
    aStatus=0xbfffec84, aView=0x4643e500) at
/psolanki/mozilla/content/events/src/nsEventStateManager.cpp:374
#9  0x4282ca06 in PresShell::HandleEventInternal (this=0x4612eb80,
aEvent=0xbfffeeb0, aView=0x4643e500, aFlags=1, aStatus=0xbfffec84)
    at /psolanki/mozilla/layout/html/base/src/nsPresShell.cpp:6147
#10 0x4282c6a0 in PresShell::HandleEvent (this=0x4612eb80, aView=0x4643e500,
aEvent=0xbfffeeb0, aEventStatus=0xbfffec84, aForceHandle=0, aHandled=@0xbfffec18)
    at /psolanki/mozilla/layout/html/base/src/nsPresShell.cpp:6076
#11 0x42a97767 in nsViewManager::HandleEvent (this=0x447d94e8, aView=0x46401170,
aEvent=0xbfffeeb0, aCaptured=0)
    at /psolanki/mozilla/view/src/nsViewManager.cpp:2207
#12 0x42a8a76d in nsView::HandleEvent (this=0x46401170, aVM=0x447d94e8,
aEvent=0xbfffeeb0, aCaptured=0) at /psolanki/mozilla/view/src/nsView.cpp:303
#13 0x42a96c67 in nsViewManager::DispatchEvent (this=0x447d94e8,
aEvent=0xbfffeeb0, aStatus=0xbfffed80) at
/psolanki/mozilla/view/src/nsViewManager.cpp:1943
#14 0x42a8a002 in HandleEvent (aEvent=0xbfffeeb0) at
/psolanki/mozilla/view/src/nsView.cpp:80
#15 0x414187f2 in nsWidget::DispatchEvent (this=0x4610d378, aEvent=0xbfffeeb0,
aStatus=@0xbfffee3c) at /psolanki/mozilla/widget/src/gtk/nsWidget.cpp:1448
#16 0x4141840a in nsWidget::DispatchWindowEvent (this=0x4610d378,
event=0xbfffeeb0) at /psolanki/mozilla/widget/src/gtk/nsWidget.cpp:1336
#17 0x414188b3 in nsWidget::DispatchMouseEvent (this=0x4610d378,
aEvent=@0xbfffeeb0) at /psolanki/mozilla/widget/src/gtk/nsWidget.cpp:1475
#18 0x41418ecb in nsWidget::OnMotionNotifySignal (this=0x4610d378,
aGdkMotionEvent=0xbfffef30) at /psolanki/mozilla/widget/src/gtk/nsWidget.cpp:1694
#19 0x4141e603 in nsWindow::OnMotionNotifySignal (this=0x4610d378,
aGdkMotionEvent=0x43a93918) at /psolanki/mozilla/widget/src/gtk/nsWindow.cpp:1634
#20 0x4141ec47 in nsWindow::HandleGDKEvent (this=0x4610d378, event=0x43a93918)
at /psolanki/mozilla/widget/src/gtk/nsWindow.cpp:1792
#21 0x4141020e in dispatch_superwin_event (event=0x43a93918, window=0x4610d378)
at /psolanki/mozilla/widget/src/gtk/nsGtkEventHandler.cpp:1001
#22 0x4140fef4 in handle_gdk_event (event=0x43a93918, data=0x0) at
/psolanki/mozilla/widget/src/gtk/nsGtkEventHandler.cpp:876
#23 0x4048fd7f in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0
#24 0x404c3773 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#25 0x404c3d39 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#26 0x404c3eec in g_main_run () from /usr/lib/libglib-1.2.so.0
#27 0x403de333 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#28 0x41405939 in nsAppShell::Run (this=0x8138b90) at
/psolanki/mozilla/widget/src/gtk/nsAppShell.cpp:347
#29 0x413aa0b5 in nsAppShellService::Run (this=0x815afb8) at
/psolanki/mozilla/xpfe/appshell/src/nsAppShellService.cpp:471
#30 0x0805da15 in main1 (argc=4, argv=0xbffff464, nativeApp=0x809fc98) at
/psolanki/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1543
#31 0x0805e6cf in main (argc=4, argv=0xbffff464) at
/psolanki/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1904
#32 0x40665657 in __libc_start_main (main=0x805e4bc <main>, argc=4,
ubp_av=0xbffff464, init=0x8056bbc <_init>, fini=0x8068f10 <_fini>, 
    rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff45c) at
../sysdeps/generic/libc-start.c:129
(gdb) quit
Yeah, other people are seeing it too (bug 186132).  I'm guessing it's not fixed
for everything, though I can't reproduce *this* bug on this site.  Maybe a
separate reason for the crash; investigating.
*** Bug 186258 has been marked as a duplicate of this bug. ***
*** Bug 186214 has been marked as a duplicate of this bug. ***
verifying build 2003-01-17-04-trunk
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsEventStateManager::DispatchMouseEvent ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: