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

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

Reassign based on recent activity to GetTarget

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

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

ccing bill law for his input.

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.

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

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.

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)

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.)

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.''

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

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

getting on Blackbird radar. Thanks for fixing this.

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

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

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.

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.

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

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

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

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.

-- 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.

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?

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 on attachment 104934 [details] [diff] [review] branch version of trunk changes sr=bzbarsky

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

r=rjc just in case

Comment on attachment 104934 [details] [diff] [review] branch version of trunk changes a=chofmann for 1.0.2

checked into branch

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

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.

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 :-(