146466 - Trunk M1RC2 N700 crashes [@ nsWindowMediator::GetTarget]

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: APIs, defect)

Description

[greer]

Pre-emptively logging this one, the crash numbers are low, but this one is
showing up in the first day of the N70PR1 Talkback reports (as well as M1RC2 and
the Trunk). Please reassign to the correct component.

(We have an internal who was able to crash this one on the Trunk but doesn't
have a bz account, so I can't cc him. I will email him to see if he can
reproduce this crash.)

User comments for M1RC2:
(6461986) - [Windows NT  5.1 build 2600] (Build 2002051008)- 2002-05-20 : Query
POP3-Server 
(6245958) - [Windows NT  5.1 build 2600] (Build 2002051008)- 2002-05-13 : just
tried to open a .gif with mozilla.... quick launch is off
(6582773) - [Windows 98  4.10 build 67766222] (Build 2002051008)- 2002-05-23 :
Closing the mail client after receiving 3 messages and forwarding one of them to
2 people  separately.


Stack trace(Frame) 

	 nsWindowMediator::GetTarget
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWindowMediator.cpp  line 993] 
	 nsWindowMediator::RemoveAndUpdateSynthetics
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWindowMediator.cpp  line 1481] 
	 nsWindowMediator::UnregisterWindow
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWindowMediator.cpp  line 292] 
	 nsWindowMediator::~nsWindowMediator
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWindowMediator.cpp  line 212] 
	 nsWindowMediator::`scalar deleting destructor'  
	 nsWindowMediator::Release
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWindowMediator.cpp  line 873] 
	 nsSupportsArray::Clear
[d:\builds\seamonkey\mozilla\xpcom\ds\nsSupportsArray.cpp  line 601] 
	 nsSupportsArray::DeleteArray
[d:\builds\seamonkey\mozilla\xpcom\ds\nsSupportsArray.cpp  line 304] 
	 nsSupportsArray::`vector deleting destructor'  
	 nsCOMPtr_base::~nsCOMPtr_base
[d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp  line 65] 
	 InMemoryDataSource::~InMemoryDataSource
[d:\builds\seamonkey\mozilla\rdf\base\src\nsInMemoryDataSource.cpp  line 942] 
	 InMemoryDataSource::`scalar deleting destructor'  
	 InMemoryDataSource::Internal::Release
[d:\builds\seamonkey\mozilla\rdf\base\src\nsInMemoryDataSource.cpp  line 965] 
	 InMemoryDataSource::Release
[d:\builds\seamonkey\mozilla\rdf\base\src\nsInMemoryDataSource.cpp  line 961] 
	 nsWindowMediator::Release
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWindowMediator.cpp  line 867] 
	 FreeServiceContractIDEntryEnumerate
[d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp  line 1835] 
	 PL_DHashTableEnumerate
[d:\builds\seamonkey\mozilla\xpcom\ds\pldhash.c  line 601] 
	 0x550004c2

Comment 1

[Doug Turner (:dougt)]

why did you assign this to the XPCOM?  How about window meditator?

Comment 2

[Adam Lock]

Reassign based on recent activity to GetTarget

Comment 3

[greer]

*** Bug 166670 has been marked as a duplicate of this bug. ***

Comment 4

[greer]

This one now has 121 incidents from the N700 release and is a topcrash. marking
as such.

Comment 5

[Shiva Thirumazhusai]

ccing bill law for his input.

Comment 6

[Jay Patel [:jay]]

Attachment: Talkback data for Netscape 7.0 crashes

The latest Talkback info for Netscape 7.0 crashes reported under the
nsWindowMediator::GetTarget stack signature.  A few stack traces and lots of
comments to help us debug this.

Comment 7

[Robert John Churchill]

QA: Does this crash still happen with trunk builds?  (The fix for *Bugscape* bug
# 16611 may have helped.)

Comment 8

[scottputterman]

Bugscape 16611 says it was checked into the branch on 6/24 which means it would
have been in NS 7.0.  According to talkback this is the #1 crash that has a
signature for NS 7.0.

Comment 9

[Jan Carpenter]

Attachment: Attaching latest comments (around 650...) and stack.

Keyword List from todays Talkback report for N700 (update is the clear winner):


activ(5), aol(5), back(12), boot(7), browser(20), button(15), click(90),
crash(64), download(82), first(4), game(4), install(32), instant(4), load(96),
log(27), mail(31), memory(4), message(48), microsoft(5), netscape(248), ogg(6),
outlook(7), play(8), shut(10), sign(6), site(4), skin(5), start(28), time(13),
update(337), upgrade(44), yahoo(4)

Comment 10

[Robert John Churchill]

QA: Please try and determine whether this happens with the trunk.  (Due to
alecf's work in bug 132175 which carved up the window mediator, stack frames
from 7.0's window mediator are a tad stale.)

Comment 11

[Samir Gehani]

rjc,
danm and I looked at this a bit since scottip brought it to my attention that
this appears to be happening alot when folks were accepting update
notifications.  Dan says:
``I'm looking at an old, 1.0 version of nsWindowMediator::GetTarget. It assumes
two pointers are valid: gRDFService and mContainer. As well they should be. But
other methods in nsWindowMediator that access gRDFService all check for null
first. Wouldn't hurt, I guess, to bail early if either mContainer or gRDFService
is null.''

Comment 12

[scottputterman]

any luck getting a patch based on Samir's comments?

Comment 13

[Robert John Churchill]

Checked in a few NULL checks against mInner and gRDFService (mContainer was
already checked).  Marking FIXED unless QA tests and can reproduce crash.

Comment 14

[scottputterman]

getting on Blackbird radar.  Thanks for fixing this.

Comment 15

[Gayatri Rimola]

Micahel, is it possible to verify this fix on the trunk?

Comment 16

[Michael Dunn]

I don't see a test case here or STR, but David can you investigate and verify as
appropriate.

Comment 17

[Jay Patel [:jay]]

A query for this stack signature in Talkback data for MozillaTrunk builds comes
up empty...so there haven't been any crashes recently on the Trunk (in the last
30 days).  Based on that, it's difficult to verify anything.

Still, since this is a major crash for Netscape 7.0, a few NULL checks won't
hurt...so we should try to get this into Blackbird and we can wait for that data
to come in to verify it after the fact.   

Comment 18

[David Epstein]

Can someone post steps for this? This would be very helpful for verifying this
bug. Also, I checked nsWindowMediator.cpp out on lxr and there is no
GetTarget(). It only goes up to line 716 whereas the crash occurs in line 993.

Comment 19

[greer]

David, the user comments (attachment in comment #9 above) point almost entirely
to accepting the automated prompt for the N7.0 update. For example: 
"Was prompted to download lastest version of Netscape 7.  Said yes  application
crashed." Those appear to be the only steps we have.

http://lxr.mozilla.org/mozilla1.0/source/xpfe/appshell/src/nsWindowMediator.cpp#979

Comment 20

[Robert John Churchill]

The file changed was mozilla/xpfe/components/windowds/nsWindowDataSource.cpp

Here is the change:  (two additional NULL checks were added)

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpfe/components/windowds&command=DIFF_FRAMESET&file=nsWindowDataSource.cpp&rev1=1.11&rev2=1.12&root=/cvsroot

Comment 21

[Gayatri Rimola]

Please verify this on the trunk so that it can be considered for the branch. Thanks.

Comment 22

[Michael Buckland]

Plussing for adt.  Need checkin by cob 10/16. Please make sure to get any
additional required  approvals (drivers) before checkin if this is not already done.

Comment 23

[dsirnapalli]

-- Verified the keywords that make sense to Mozilla trunk. The crash was
happenning mainly because of the browser upgrade notice dialog in Netscape. That
cannot be verified in the trunk. Verified the comments from users which ever
make sense to Mozilla trunk.
Also there is no crash reported by talkback on trunk with the stack
id(nsWindowMediator::GetTarget) in the recent days.
Didnot crash anytime with the testing i have done.
Marking the bug verified.

Comment 24

[Michael Buckland]

Asked via email rjc:  it looks like it was fixed on the trunk but on the branch.
 Blackbird wants this fix, but we need it checked in asap.  Will your trunk
patch work on the branch or do you need to do additional work for the branch?

When you are ready do you want me to ask for drivers approval for the branch?

Comment 25

[Daniel Veditz [:dveditz]]

Without the upgrade notifications being sent out this is no longer the #1 crash
in 7.0, but it's still a popular one at #10. Comments now reflect lots of things
that do happen in Mozilla -- shutting down and reading mail seem to be in the
comments a lot, but a lot of misc. stuff too.

Comment 26

[Daniel Veditz [:dveditz]]

Attachment: branch version of trunk changes

Comment 27

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 104934 [details] [diff] [review]
branch version of trunk changes

sr=bzbarsky

Comment 28

[Samir Gehani]

Comment on attachment 104934 [details] [diff] [review]
branch version of trunk changes

r=sgehani

Comment 29

[Robert John Churchill]

r=rjc just in case

Comment 30

[chris hofmann]

Comment on attachment 104934 [details] [diff] [review]
branch version of trunk changes

a=chofmann for 1.0.2

Comment 31

[Daniel Veditz [:dveditz]]

checked into branch

Comment 32

[Michael Dunn]

David, or Ashish -- 
Since Dharma is out can youverify this on the branch ASAP?

Comment 33

[Ashish Bhatt]

Marking as verified on 1.0.2 as per changes in the attachment (id=100063) in
nsWindowMediator.cpp

There is no real way to reproduce or verify this crash on 1.0.2 branch  because
the the upgrade notice which caused this crash will not appear for this branch.

Tried installing netscape many time from the upgrade page and changing user
agent string to that of NS7PR1. Crash did not happen.

Comment 34

[Daniel Veditz [:dveditz]]

This was never particularly reproducable, lots of people got the update
notifications just fine. Even with those turned off this signature remains in
the top ten on windows (#9 in todays report) so you might be able to trigger it
in other ways. But I think the only way to really verify this is through
talkback data. Unfortunately the Mozilla 1.0 builds are only getting 32 crashes
in a ten day window and this crash is already not present on the list so we'll
have to wait for Blackbird to ship to see if this worked :-(