174812 - M120A topcrash [@ nsXULPrototypeDocument::GetNodeInfoManager]

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Jan Carpenter]

This stack signature is a topcrasher for the M120A
Rank    StackSignature    Count  

19   nsXULPrototypeDocument::GetNodeInfoManager   32 

 
 	Source File :
c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULPrototypeDocument.cpp
line : 626
 
====================================================================================================
     Count   Offset    Real Signature
[ 6   nsXULPrototypeDocument::GetNodeInfoManager f9c5950f -
nsXULPrototypeDocument::GetNodeInfoManager ]
[ 2   nsXULPrototypeDocument::GetNodeInfoManager 5a1c19db -
nsXULPrototypeDocument::GetNodeInfoManager ]
[ 1   nsXULPrototypeDocument::GetNodeInfoManager f5d80f56 -
nsXULPrototypeDocument::GetNodeInfoManager ]
[ 1   nsXULPrototypeDocument::GetNodeInfoManager 413414a3 -
nsXULPrototypeDocument::GetNodeInfoManager ]
 
     Crash date range: 2002-10-06 to 2002-10-15
     Min/Max Seconds since last crash: 290 - 719083
     Min/Max Runtime: 36682 - 951897
     Keyword List :  
     Count   Platform List 
     6   Windows 98 4.10 build 67766446
     3   Windows NT 5.0 build 2195
     1   Windows 98 4.90 build 73010104
 
     Count   Build Id List 
     10   2002091014
 
     No of Unique Users         8
 
 Stack trace(Frame) 

	 nsXULPrototypeDocument::GetNodeInfoManager
[c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULPrototypeDocument.cpp
 line 626] 
	 nsXULElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp  line 3381] 
	 nsXULElement::HandleChromeEvent
[c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp  line 4688] 
	 GlobalWindowImpl::HandleDOMEvent
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp  line 762] 
	 DocumentViewerImpl::Unload
[c:/builds/seamonkey/mozilla/content/base/src/nsDocumentViewer.cpp  line 1016] 
	 nsDocShell::FireUnloadNotification
[c:/builds/seamonkey/mozilla/docshell/base/nsDocShell.cpp  line 796] 
	 nsDocShell::CreateContentViewer
[c:/builds/seamonkey/mozilla/docshell/base/nsDocShell.cpp  line 4252] 
	 nsDSURIContentListener::DoContent
[c:/builds/seamonkey/mozilla/docshell/base/nsDSURIContentListener.cpp  line 111] 
	 nsDocumentOpenInfo::DispatchContent
[c:/builds/seamonkey/mozilla/uriloader/base/nsURILoader.cpp  line 424] 
	 nsDocumentOpenInfo::OnStartRequest
[c:/builds/seamonkey/mozilla/uriloader/base/nsURILoader.cpp  line 230] 
	 nsHttpChannel::ProcessNormal
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp  line 631] 
	 nsHttpChannel::ProcessResponse
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp  line 586] 
	 nsHttpChannel::OnStartRequest
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp  line
2873] 
	 nsOnStartRequestEvent::HandleEvent
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsRequestObserverProxy.cpp  line 162] 
	 PL_HandleEvent	[c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c  line 644] 
	 PL_ProcessPendingEvents	[c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c 
line 577] 
	 _md_EventReceiverProc	[c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c 
line 1309] 
	 KERNEL32.DLL + 0x24407 (0xbff94407)  
	 0x00648bf6   


URLs\COMMENTS:

(12599540) URL: http://personals.theonion.com/personals/preview_ad.asp?PRID=2815869

(12379405)	URL: www.personals.salon.com

Comment 1

[Brendan Eich [:brendan]]

Was this from a nightly?  nsXULElement::HandleDOMEvent does not call
nsXULPrototypeDocument::GetNodeInfoManager, and I don't believe it ever did.

/be

Comment 2

[Brendan Eich [:brendan]]

If this stack is nonsense, and it came from a nightly, this could be yet another
dup of the bug bryner found, where typelibs weren't being linked together and
installed correctly.

/be

Comment 3

[John Morrison]

Yes, I don't see (in lxr/bonsai) anytime when ...::HandleDOMEvent called
...::GetNodeInfoManager, either in the trunk or the 1.0 branch.

I did a query of all talkback with nsXULPrototypeDocument::GetNodeInfoManager
at top of stack. I got the following build ids:

  2002082310 - Gecko1.0           70     mozilla1.0rc2
  2002082608 - Gecko1.0            1     mozilla1.0
  2002091014 - MozillaTrunk       67     mozilla1.2a

One thing to note is that this (apparently) only shows up in the release 
builds. Whether that is due to the build bits as shipped, or due to a problem 
that occurs after long use of a particular build isn't clear (the assumption 
being that people who run nightlies move on to another nightly after a few 
days, and only release builds get used over an extended period of time).

I also happened to notice that the crash reports with this stack had (what I 
think is) very long runtimes: the average is just over 4 days, with 30% running 
a day or less, 60% running 1 to 10 days, and 10% are greater than 11 days. No 
crash occurred earlier than 10 minutes into the session. But maybe that's not 
significant and those are typical numbers for people using release builds. (I 
don't know since for testing, I am probably starting/quitting dozens of times a 
day).

(Actually, given http://bugzilla.mozilla.org/show_bug.cgi?id=167622#c17, it 
appears that 1.0rc2 was notably more unstable than what we released after
the final few fixes).

Comment 4

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 5

[Jan Carpenter]

no incidents with this stack signature reported in over a month.  Marking fixed.
 Reopen if necessary.