135498 - Navigating exclusively in tabs crashes browser - Trunk M100 [@ nsEventStateManager::GetEventTargetContent]

Status: VERIFIED FIXED

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

Description

[Anthony Jenkins]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020404
BuildID:    2002040403

This may be a dupe...I saw several reports that were similar, but none of them
described crashes while opening new tabs.

System:
Win98SE
IE 5.5
Visual Studio 6.0 (Visual C++ and Visual Basic)

When browsing exclusively via right clicking and opening pages in new tabs, the
browser will invariably crash after a (fairly small) number of pages have been
opened in this manner.  The limit is usually four to ten new tabs (closing some,
opening new ones, etc...).

The crash always occurs after the new tab is shown, but before the document
interface is drawn.

The text of the fault dialog is:

  MOZILLA caused an invalid page fault in
  module GKCONTENT.DLL at 017f:602fd28e.
  Registers:
  EAX=00000000 CS=017f EIP=602fd28e EFLGS=00010202
  EBX=00000000 SS=0187 ESP=0064f930 EBP=0064f948
  ECX=6033a330 DS=0187 ESI=02311448 FS=3a5f
  EDX=0064f968 ES=0187 EDI=02032d64 GS=0000
  Bytes at CS:EIP:
  ff 50 54 eb 06 8b 45 10 83 20 00 5f 33 c0 5e 5d 
  Stack dump:
  02032d64 0083c300 0064fb0c 0064f968 0258fea8 0258fe80 0064f974
  60300c97 02311448 0064fb0c 0064f968 00000000 021c62a0 0064fb0c
  00000000 02311448 

I have experienced this problem in release builds of 0.9.7, 0.9.9 and in the
daily build 0.9.9.2002040403

Reproducible: Always
Steps to Reproduce:
1. Visit any page with a lot of links (mozilla.org is useful)
2. Open links via right-clicking and choosing New Tab (I usually press the "T" key)
3. Continue doing this, leaving some tabs open, closing others.  I am usually
focused on the FIRST tab for navigation, though I will often open pages from
subsequent tabs, as well.

Actual Results:  Browser will crash. 

Expected Results:  Browser should not crash.

Information on three crashes in this manner was submitted via Talkback:

TB4827731K
TB4827382Q
TB4825217Q

Comment 1

[André Dahlqvist]

Quiet likely a duplicate of bug 134664. We need the stack from the talkback
reports to compare.

Comment 2

[André Dahlqvist]

nsEventStateManager::GetEventTargetContent 4c037cf2)
    nsEventStateManager::GetEventTargetContent
<javascript:OpenAuxWindow(0, 4827731, 0)>
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp,
line 3367]
    nsDOMEvent::GetTarget <javascript:OpenAuxWindow(1, 4827731, 0)>
[d:\builds\seamonkey\mozilla\content\events\src\nsDOMEvent.cpp, line 336]
    nsXULElement::HandleDOMEvent <javascript:OpenAuxWindow(2, 4827731,
0)>
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp,
line 3425]
    HandleImagePLEvent <javascript:OpenAuxWindow(3, 4827731, 0)>
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsImageFrame.cpp, line
494]
    HandleImageOnloadPLEvent <javascript:OpenAuxWindow(4, 4827731, 0)>
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsImageBoxFrame.cpp,
line 155]
    PL_HandleEvent <javascript:OpenAuxWindow(5, 4827731, 0)>
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 597]
    PL_ProcessPendingEvents <javascript:OpenAuxWindow(6, 4827731, 0)>
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 530]
    _md_EventReceiverProc <javascript:OpenAuxWindow(7, 4827731, 0)>
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1078]
    KERNEL32.DLL + 0x24407 (0xbff94407) <javascript:OpenAuxWindow(8,
4827731, 0)>
    0x00648c16 <javascript:OpenAuxWindow(9, 4827731, 0)>

Comment 3

[Jay Patel [:jay]]

Confirming this bug, it's been a topcrasher on the MozillaTrunk for a few days now:

nsEventStateManager::GetEventTargetContent   27
		 78574 	 VERI 	 FIXE 	 [e-mail] 	 mozilla0.9.1 	 2001-05-10 
BBID range: 5122159 - 5441834
Min/Max Seconds since last crash: 45 - 53833
Min/Max Runtime: 45 - 92947
Crash data range: 2002-04-12 to 2002-04-21
Build ID range: 2002041206 to 2002041914
Keyword List : 
Stack Trace: 

	 nsEventStateManager::GetEventTargetContent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp  line 3385]
	 nsDOMEvent::GetTarget
[d:\builds\seamonkey\mozilla\content\events\src\nsDOMEvent.cpp  line 336]
	 nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp  line 3354]
	 HandleImagePLEvent
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsImageBoxFrame.cpp  line 145]
	 HandleImageOnloadPLEvent
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsImageBoxFrame.cpp  line 155]
	 PL_HandleEvent
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 597]
	 PL_ProcessPendingEvents
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 530]
	 _md_EventReceiverProc
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 1078]
	 nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp  line 309]
	 main1
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1430]
	 main
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1765]
	 WinMain
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1783]
	 WinMainCRTStartup()
	 KERNEL32.DLL + 0xd326 (0x77e8d326)
 
 	Source File :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/events/src/nsEventStateManager.cpp
line : 3385
     (5441834)	URL: www.jubii.dk
     (5418363)	Comments: I opened link by new tab.
     (5353446)	URL: www.hotmail.com

Adding crash keywords, qawanted to see if we can get this reproduced and
nominating for nsbeta1.

Comment 4

[Paul Wyskoczka]

Sarah, could you take a look at this crash and see if you can reproduce the
crash. Thanks.

Comment 5

[sairuh (rarely reading bugmail)]

i haven't encountered this crash with recent builds from the branch on linux
rh7.2, where i use tabs all the time.

i often use tabs on win2k and mac 10.1.4 as well, and i haven't encountered a
crash like this either.

at first i thought this would be bug 134664, which was fixed on 10 april.
however, Jay sez that the builds for current reports range from 12 - 19 april
--but from the trunk. could this be trunk only?

i'll grab today's trunk bits, but i'll keep qawanted since i have been spending
more time on the branch recently --until i (or another person) come up with a
good recipe or two.

Comment 6

[sairuh (rarely reading bugmail)]

so far haven't encountered this crash using 2002.04.24.12-trunk (commercial)
bits on linux rh7.2...

Jay, what platforms is this crash occurring on? win32-only, or others?

Comment 7

[Jay Patel [:jay]]

Sairuh: Talkback data for this stack signature is only showing crashes on Win32
machines.   But if you have been crashing on Linux it might be worth finding out
what stack signature the Linux crashes are being reported under.

This crash appears to be on the Mozilla1.0 branch as well, since there are a few
crashes with Mozilla1.0 RC1.

Comment 8

[sairuh (rarely reading bugmail)]

jay, thanks for the info! will play around more with win2k bits today...

Comment 9

[sairuh (rarely reading bugmail)]

hrm, so far i haven't been able to get a crash using either 2002.04.25.08-gmake
(trunk) or 2002.04.25.08-1.0.0 (branch) commercial bits on win2k.

out of curiosity, for thos who're encountering this: how soon after you start
mozilla (or netscape) d'you see this? how frequently do you see this? also, are
you using QuickLaunch? (btw, i'm not currently using QuickLaunch.)

Comment 10

[Peter Trudelle]

nsbeta1+/adt2 per Nav triage team

Comment 11

[Peter Trudelle]

Is this still happening?  Talkback server seems to be down right now...

Comment 12

[greer]

Attachment: Stack, Parameters/Values and code for incident 5983904.

Peter, Talkback shows this signature is still happening on the Trunk with ten
crashes in these Windows builds:
2002050508
2002050408
2002050108
2002043010
2002042603

Here is a single signature with some of the code information, including values
at the time of the crash.

Comment 13

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 82618 [details]
Stack, Parameters/Values and code for incident 5983904.

>nsEventStateManager::GetEventTargetContent [nsEventStateManager.cpp, line 3385]

>3383   if (mCurrentTarget) {
>3384     mCurrentTarget->GetContentForEvent(mPresContext, aEvent, aContent);
>3385     return NS_OK;    <-- Always returning a positive value
>3386   }

This suggests that perhaps mCurrentTarget is pointing to a destroyed
frame.	Disassembly and registers would be the only way to tell for
sure, though.

If that's the case, it might be easier to reproduce the bug if you apply
the patches in bug 114219 and bug 114221 (in a debug build).

Comment 14

[greer]

Attachment: Disassambly and Registers

dbaron, registers and disassembly for your viewing pleasure.

Comment 15

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Yeah, definitely looks like mCurrentTarget was destroyed -- its vtable pointer
is null (that's what's in EAX).

Comment 16

[Peter Trudelle]

Why isn't this topcrash+?

Comment 17

[Shiva Thirumazhusai]

->topcrash+ (possible oneliner fix.)

Comment 18

[jag (Peter Annema)]

-> Events, maybe they can make sense of this.

Comment 19

[jag (Peter Annema)]

Sorry, wrong events component.

Comment 20

[Jay Patel [:jay]]

making topcrash+ again (the + was somehow removed)

Comment 21

[scottputterman]

changing impact to [adt2 rtm] per adt.

Comment 22

[Jaime Rodriguez, Jr.]

Tom - Haven't seen a comment form you in this bug. Any idea on how close we are
to resolving this one? Pls add your ETA to the Status Whiteboard. thanks!

Comment 23

[Jay Patel [:jay]]

Updating summary with M100, this has been a topcrasher for Mozilla 1.0 (although
there are only 38 crashes out of the current datasample of 13000).  Still, it is
a topcrasher at #43 for that release.  

Any progress here?  No one has looked at this bug for a while. 

Comment 24

[Peter Trudelle]

Current assignee has not accepted, or even commented on this topcrash bug. Can
anyone else take it?

Comment 25

[timeless]

ok

Comment 26

[joki (gone)]

I tried to repro this before and didn't have any luck so I kind of back-burner'd
it for a while.  Looking at it again I think I may have a good idea what the
issue is.  The issue is likely with code looking back for old data which isn't
there anymore when using PostDOMEvent.  I'll post a possible patch but without
being able to replicate this I can't test how well it works very easily.

Comment 27

[Jaime Rodriguez, Jr.]

saari, should this one go to joki, since he is looking into it, and has a
possible patch?

Comment 28

[saari (gone)]

yes, back to tom

Comment 29

[joki (gone)]

Okay, a fix has been checked into the trunk and branch (for bug 157845).  Since
I can't repro this bug I can't verify that the fix will take care of this also
but the stack traces seem to indicate that both should be fixed.  Rather then
dupe this one I'm just going to mark this one fixed for now and we should watch
the talkback data to see if this one goes away.

Comment 30

[Vladimir Ermakov]

[e-mail] (Anthony Jenkins), or anyone else who reproduced the problem
before, can you please verify with latest build?

Comment 31

[Vladimir Ermakov]

verifying due to lack of responce, if this was still present people would speak up..