Closed Bug 414808 Opened 13 years ago Closed 13 years ago

###!!! ASSERTION: Oops! You're asking for a weak reference to an object that doesn't support that.: 'factoryPtr'

Categories

(Core :: Security: PSM, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9beta3

People

(Reporter: cbook, Assigned: KaiE)

References

()

Details

(Keywords: assertion)

Attachments

(2 files)

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008012923 Firefox/3.0b3pre


###!!! ASSERTION: Oops!  You're asking for a weak reference to an object that doesn't support that.: 'factoryPtr', file nsWeakReference.cpp, line 109

Steps to reproduce:

Go to addons.mozilla.org -> Assertion
Attached file stack
This seems bad since the observer wont be registered in this case.
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/xpcom/ds/nsObserverList.cpp&rev=3.42&root=/cvsroot&mark=57-59#44
Assignee: nobody → kengert
Component: General → Security: PSM
Flags: blocking1.9?
OS: Mac OS X → All
QA Contact: general → psm
Hardware: PC → All
Drivers: Requested blocking and TM 1.9b3 because of comment #2
Target Milestone: --- → mozilla1.9beta3
Kaie - is this related to bug 414997?
Do we know what at addons.mozilla.org is causing this call? Is it something that affects a lot of websites?
Connecting to any https site triggers this assertion.
Ok. I have done some testing with debug builds.  This happens on Windows XP as well as Mac OS X 10.5.

Pulling source with a date of Jan 27, 2008 04:00AM PDT does NOT produce this error.  That means it is something checked in between today and sunday that broke it. It's a wide window given the rush before the freeze, but my money is on the netwerk/nspr changes, given that it only happens on https.

Here are the network nspr changes in this timewindow.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fnspr+mozilla%2Fnetwerk&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-31+04%3A00%3A00&maxdate=2008-01-27+04%3A00%3A00&cvsroot=%2Fcvsroot

This is a regression from the rush to the freeze.  I recommend that this blocks FFx 3 Beta 3.
Clint, thanks a lot for your analysis.
CC'ing people who work on NSPR, please see the previous comment.
Until we have a clear sense of impact, we're going to block beta 3 for this.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P1
Kai,

I'm not really sure what this has to do with NSPR. I didn't see any NSPR function in the reported stack. If you agree that this is unrelated to NSPR, please remove me from the cc list for this bug.
Who is able to reproduce this bug and could test the effect of switching back to an earlier snapshot of NSPR?

In order to test this, please change NSPR_CO_TAG in mozilla/client.mk to NSPR_HEAD_20080120 (the value in effect at the date mentioned in comment 7).

Unfortunately I don't see the assertion, so I can't test myself.
I don't really see anything in this bug related to NSPR. What I do see, based on the stack from Mats, is that nsCertOverrideService attempts to add itself as an observer with a weakref, without implementing nsIWeakReference. The patch from bug 406612 caused us to instantiate the cert override service on the first SSL pageload.
The changes made there introduced a call to certOverrideService as part of SSL
pageloads, in order to establish what to say in the tooltip ("Verified by:
Equifax" vs. "This site has a security exception").  I don't think there's
anything buggy in the code calling it, but it is plausibly the thing that
exposed this assertion.

The service is cached after first access though, so if this is it, it should
only happen once per session, I think.
(In reply to comment #11)
> Who is able to reproduce this bug and could test the effect of switching back
> to an earlier snapshot of NSPR?
> 
> In order to test this, please change NSPR_CO_TAG in mozilla/client.mk to
> NSPR_HEAD_20080120 (the value in effect at the date mentioned in comment 7).
> 
> Unfortunately I don't see the assertion, so I can't test myself.
> 

I have done the test and this change does no change (as expected). 

(In reply to comment #13)
> 
> The service is cached after first access though, so if this is it, it should
> only happen once per session, I think.
> 

Yes, confirmed, i see 3
###!!! ASSERTION: Oops!  You're asking for a weak reference to an object that doesn't support that.: 'factoryPtr', file nsWeakReference.cpp, line 109
###!!! ASSERTION: Oops!  You're asking for a weak reference to an object that doesn't support that.: 'factoryPtr', file nsWeakReference.cpp, line 109
###!!! ASSERTION: Oops!  You're asking for a weak reference to an object that doesn't support that.: 'factoryPtr', file nsWeakReference.cpp, line 109

in a row, but not later in the session, even when i browse to other SSL Sites as example
I'm now able to reproduce.

It looks adding support for weak references to the cert override service is sufficient to fix this bug.

When I tried to test it, I remembered bug 413627 which was waiting for my review for exactly that change.

I've tested that patch, and it works for me!
I requested approval for beta 3 in bug 413627.
So, regarding the impact, I now understand better what's happening.

This seems strictly limited to the cert override service, which is unable to hook up to profile change notifications.

As a result, on a profile change it will be unable to read in stored cert exceptions. It will be unable to cleanup its storage file when profile manager requests to erase a profile.
(In reply to comment #15)
> I've tested that patch, and it works for me!

Confirmed, i don't get the assertion in a new debug build with the patch from Bug 413637

Attached file crash log
(In reply to comment #17)
> (In reply to comment #15)
> > I've tested that patch, and it works for me!
> 
> Confirmed, i don't get the assertion in a new debug build with the patch from
> Bug 413637
> 

Note: now i crash on exit with the debug build that include this patch, see crash log , Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008013119 Firefox/3.0b3pre

NSPR_CO_TAG          = NSPR_HEAD_20080129_PLUS_414997
Attachment #300822 - Attachment mime type: application/text → text/plain
and also the last debug output message is :

Assertion failure: 0 == rv, at /debug/mozilla/nsprpub/pr/src/pthreads/ptsynch.c:207
this crash is fixed by patch https://bugzilla.mozilla.org/attachment.cgi?id=300826 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008013119 Firefox/3.0b3pre and this patch included 

Drivers: can we have this patch in beta 3, since this and the Bug 413627 is also blocking beta 3, thanks :)
marking fixed based on the checkin for bug 413627 and based on Tomcat's comment 20.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008020601 Firefox/3.0b4pre also per comment #20

-> Verified fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.