69589 - M08 & trunk Crash on AIM Express [@ nsEventStateManager::UpdateCursor]

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Peter Lubczynski]

Visit AIM Express with a trunk pull and notice all the assertions, then a crash 
in layout (GKCONTENT). Oddly enough, if you wait long enough during an 
assertion dialog, the Java applet actually loads and looks like it's going to 
work if it wasn't for all the assertions and then the final crash. I think 
busyFlags is pointing off into space. I think this is layout, but throw it back 
to me if it's plugins. 

Here's the stack trace:

nsEventStateManager::UpdateCursor(nsIPresContext * 0x16300840, nsEvent * 
0x0012f80c, nsIFrame * 0x164226fc, nsEventStatus * 0x0012f700) line 1485 + 18 
bytes
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x16311e60, 
nsIPresContext * 0x16300840, nsEvent * 0x0012f80c, nsIFrame * 0x164226fc, 
nsEventStatus * 0x0012f700, nsIView * 0x162c0a88) line 316
PresShell::HandleEventInternal(nsEvent * 0x0012f80c, nsIView * 0x162c0a88, 
unsigned int 1, nsEventStatus * 0x0012f700) line 4841 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x162368bc, nsIView * 0x162c0a88, 
nsGUIEvent * 0x0012f80c, nsEventStatus * 0x0012f700, int 0, int & 1) line 4782 + 
25 bytes
nsView::HandleEvent(nsView * const 0x162c0a88, nsGUIEvent * 0x0012f80c, unsigned 
int 8, nsEventStatus * 0x0012f700, int 0, int & 1) line 372
nsView::HandleEvent(nsView * const 0x00ce5a50, nsGUIEvent * 0x0012f80c, unsigned 
int 8, nsEventStatus * 0x0012f700, int 0, int & 1) line 345
nsView::HandleEvent(nsView * const 0x163e0100, nsGUIEvent * 0x0012f80c, unsigned 
int 28, nsEventStatus * 0x0012f700, int 1, int & 1) line 345
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x163eff10, nsGUIEvent * 
0x0012f80c, nsEventStatus * 0x0012f700) line 1424
HandleEvent(nsGUIEvent * 0x0012f80c) line 68
nsWindow::DispatchEvent(nsWindow * const 0x00ce5b0c, nsGUIEvent * 0x0012f80c, 
nsEventStatus & nsEventStatus_eIgnore) line 687 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f80c) line 708
nsWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 3949 + 
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 
4159
nsWindow::ProcessMessage(unsigned int 512, unsigned int 0, long 26673731, long * 
0x0012fbc0) line 2943 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x001201ae, unsigned int 512, unsigned int 0, long 
26673731) line 923 + 27 bytes
USER32! 77e148dc()
USER32! 77e14aa7()
USER32! 77e266fd()
nsAppShellService::Run(nsAppShellService * const 0x00b90228) line 408
main1(int 1, char * * 0x004a7b38, nsISupports * 0x00000000) line 978 + 32 bytes
main(int 1, char * * 0x004a7b38) line 1270 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e992a6()

Comment 1

[Peter Lubczynski]

Attachment: Screenshot of warning about crash (Thanks AOL!)

Comment 2

[av (gone)]

This worked for me with just pulled debug build. I was able to sign on and chat.

Comment 3

[Peter Lubczynski]

I just pulled this morning. Strange. 

Shrir, can you try this as well?

Comment 4

[av (gone)]

I am on NT4.0. Could be that but unlikely.

Comment 5

[Keyser Sose]

Possible dupe of 67670? Thoughts?

Comment 6

[karnaze (gone)]

reassigning to buster's list.

Comment 7

[Jan Carpenter]

This is a topcrash for mozilla 0.8 
adding topcrash keyword, M08 and [@ nsEventStateManager::UpdateCursor] for 
tracking

Here's the latest stack trace:

Incident ID 26826238 
nsEventStateManager::UpdateCursor 
[d:\builds\0.8\mozilla\layout\events\src\nsEventStateManager.cpp, line 1427] 
nsEventStateManager::PreHandleEvent 
[d:\builds\0.8\mozilla\layout\events\src\nsEventStateManager.cpp, line 303] 
PresShell::HandleEventInternal 
[d:\builds\0.8\mozilla\layout\html\base\src\nsPresShell.cpp, line 4911] 
PresShell::HandleEvent 
[d:\builds\0.8\mozilla\layout\html\base\src\nsPresShell.cpp, line 4851] 
nsView::HandleEvent [d:\builds\0.8\mozilla\view\src\nsView.cpp, line 372] 
nsView::HandleEvent [d:\builds\0.8\mozilla\view\src\nsView.cpp, line 345] 
nsView::HandleEvent [d:\builds\0.8\mozilla\view\src\nsView.cpp, line 345] 
nsViewManager2::DispatchEvent 
[d:\builds\0.8\mozilla\view\src\nsViewManager2.cpp, line 1424] 
HandleEvent [d:\builds\0.8\mozilla\view\src\nsView.cpp, line 68] 
nsWindow::DispatchEvent [d:\builds\0.8\mozilla\widget\src\windows\nsWindow.cpp, 
line 691] 
USER32.dll + 0x1a43f (0x77e8a43f) 
nsWindow::DispatchMouseEvent 
[d:\builds\0.8\mozilla\widget\src\windows\nsWindow.cpp, line 3951] 
ChildWindow::DispatchMouseEvent 
[d:\builds\0.8\mozilla\widget\src\windows\nsWindow.cpp, line 4159] 
nsWindow::ProcessMessage [d:\builds\0.8\mozilla\widget\src\windows\nsWindow.cpp, 
line 2991] 
nsWindow::WindowProc [d:\builds\0.8\mozilla\widget\src\windows\nsWindow.cpp, 
line 924] 
USER32.dll + 0x1820 (0x77e71820) 
0x00a1026e 

and here are some user comments and URLs to help reproduce:

        URL:(26937830) mycnn.com
        URL:(26950869) www.herrschners.com
        URL:(26661911) www.obersparpfennig.de
        URL:(26686719) http://www.bestbytes.de
        URL:(26986654) www.netfunny.org
        URL:(26623977) www.freewarepub.net
        URL:(26613092) 
http://slashdot.org/article.pl?sid=01/02/13/0720252&mode=thread
        URL:(26826238) http://my.yahoo.com
        URL:(27404004) http://www.zfmicro.com
        Comment: (26937830) save&close layout customization
        Comment: (27293569) going back several pages in history
        Comment: (26661911) denying the loading of images
        Comment: (27212523) Loading the following
page<HTML><HEAD><SCRIPT>var tid;function closeWin () {  tid =
setTimeout('window.close()'
        Comment: (27212523)  (document.body.all[e].onfocus) {
        Comment: (27212523)      }
        Comment: (27212523)  ONFOCUS="window.status = 'enter name'">
        Comment: (26686719) clicked a link button; maybe
unintentionally clicked it twice;(btw.this site attempts to
dynamically set the positon of a div on mouseover events of the
button.)
        Comment: (26986654) clicking on a link
        Comment: (26623977) Set up browser to ask me before accepting
images.  I was accepting/rejecting images when the browser crashed.
        Comment: (26613092) I clicked a link and then quickly pressed
the stop button (did not mean to click the link).
        Comment: (26826238) Selected bookmark from menuDr.
Watson:Exception: access violation (0xc0000005)
        Comment: (27168740) I was looking at www.slashdot.org and
trying to follow a link to one of the old "Ask Slashdot" articles
        Comment: (27320150) clicked the "delete" button in a
Microsoft Exchange outlook-for-theweb mail message
        Comment: (27404004) trying to enlarge an image

Comment 8

[Blake Ross]

buster's gone.  -> saari, cc joki

Comment 9

[Peter Lubczynski]

Note: This WFM in Windows builds on 2/23 builds at home. And Andrei says it 
works. I'm willing to mark this WFM if it wasn't for all the Top Crash data. But 
this isn't a plugin issue.

Comment 10

[Peter Lubczynski]

This happens if you move the cursor in a special way. We get a null DocShell in 
the event state manager. I have a patch for this at home I will attach shortly. 

Comment 11

[Curt Patrick (gone)]

Adding "trunk" in the summary and changing OS to "All". A series of these 
bugs have been showing up in the top 20 bugs of nightly trunk builds on both 
Linux and Windows.

Comment 12

[saari (gone)]

Peter, please attach your patch, this is a top crash now. Thanks!

Comment 13

[Peter Lubczynski]

Attachment: simple null pointer check

Comment 14

[Peter Lubczynski]

I think this does it for me. Can anyone else who is seeing this try out my 
patch? review? Thanks!

Comment 15

[selmer (gone)]

Using nscatfood keyword to track crash car bugs.

Comment 16

[Marc Attinasi]

Woo Hoo! [s]r=attinasi on attachID=27750

Are we having another problem that still should be investigated here? Clearly,
checking for null is good, but I'd worry about a deeper bug we might be masking...

Comment 17

[saari (gone)]

r=saari, but could someone comment on the way you have to move the cursor to get
a null docshell? I'm curious...

Comment 18

[Peter Lubczynski]

I'm not exactly sure as I can only reproduce it sometimes. I'm more concerned 
about the talkback data.

Comment 19

[Peter Lubczynski]

Patch checked in.

===>new revision: 1.243; previous revision: 1.242

Comment 20

[Chris Petersen]

Marking verified per last comments.