Closed Bug 146466 Opened 22 years ago Closed 22 years ago

Trunk M1RC2 N700 crashes [@ nsWindowMediator::GetTarget]

Categories

(Core Graveyard :: Embedding: APIs, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: greer, Assigned: mozilla)

References

Details

(Keywords: crash, qawanted, topcrash)

Crash Data

Attachments

(3 files)

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
Keywords: crash
why did you assign this to the XPCOM?  How about window meditator?
Assignee: dougt → adamlock
Component: XPCOM → Embedding: APIs
QA Contact: scc → mdunn
Reassign based on recent activity to GetTarget
Assignee: adamlock → rjc
*** 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.
Keywords: qawanted, topcrash
Summary: Trunk M1RC2 N70PR1 crashes [@ nsWindowMediator::GetTarget] → Trunk M1RC2 N700 crashes [@ nsWindowMediator::GetTarget]
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.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
getting on Blackbird radar.  Thanks for fixing this.
Keywords: adt1.0.2
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.
QA Contact: mdunn → depstein
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
QA Contact: depstein → dsirnapalli
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.
Keywords: adt1.0.2adt1.0.2+
-- 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.
Status: RESOLVED → 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
Attachment #104934 - Flags: superreview+
Comment on attachment 104934 [details] [diff] [review]
branch version of trunk changes

r=sgehani
Attachment #104934 - Flags: review+
r=rjc just in case
Comment on attachment 104934 [details] [diff] [review]
branch version of trunk changes

a=chofmann for 1.0.2
Attachment #104934 - Flags: approval+
checked into branch
Keywords: mozilla1.0.2fixed1.0.2
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 :-(
Crash Signature: [@ nsWindowMediator::GetTarget]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: