Start-up crash with incompatible version of some extensions [@ nsTArray<ObserverRef, nsTArrayDefaultAllocator>::AppendElements<ObserverRef>(ObserverRef const*, unsigned int) | nsObserverList::FillObserverArray(nsCOMArray<nsIObserver>&) ]

RESOLVED WONTFIX

Status

()

defect
--
critical
RESOLVED WONTFIX
8 years ago
10 months ago

People

(Reporter: scoobidiver, Unassigned)

Tracking

({crash, regression, reproducible})

unspecified
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox5+)

Details

(crash signature)

It exists in 4.0.1, 5.0 and 6.0a1.
It is currently #1 top crasher in 5.0b2.
It happens at startup.

Stack traces are various:
0 	xul.dll 	nsTArray<ObserverRef,nsTArrayDefaultAllocator>::AppendElements<ObserverRef> 	obj-firefox/dist/include/nsTArray.h:773
1 	xul.dll 	nsObserverList::FillObserverArray 	xpcom/ds/nsObserverList.cpp:102
2 	xul.dll 	SearchTable 	obj-firefox/xpcom/build/pldhash.c:439
3 	xul.dll 	xul.dll@0x65c9f 	
4 	xul.dll 	nsHttpChannel::AsyncOpen 	netwerk/protocol/http/nsHttpChannel.cpp:3652
5 	xul.dll 	nsURILoader::OpenURI 	uriloader/base/nsURILoader.cpp:863
6 	xul.dll 	nsDocShell::DoChannelLoad 	docshell/base/nsDocShell.cpp:9048
7 	xul.dll 	nsDocShell::DoURILoad 	docshell/base/nsDocShell.cpp:8890
8 	xul.dll 	nsDocShell::InternalLoad 	docshell/base/nsDocShell.cpp:8555 

0 	xul.dll 	nsTArray<ObserverRef,nsTArrayDefaultAllocator>::AppendElements<ObserverRef> 	obj-firefox/dist/include/nsTArray.h:773
1 	xul.dll 	nsObserverList::FillObserverArray 	xpcom/ds/nsObserverList.cpp:102
2 	xul.dll 	SearchTable 	obj-firefox/xpcom/build/pldhash.c:439
3 	xul.dll 	xul.dll@0x65c9f 	
4 	xul.dll 	nsHttpChannel::AsyncOpen 	netwerk/protocol/http/nsHttpChannel.cpp:3652
5 	xul.dll 	nsXMLHttpRequest::Send 	content/base/src/nsXMLHttpRequest.cpp:2204
6 	xul.dll 	nsIXMLHttpRequest_Send 	obj-firefox/js/src/xpconnect/src/dom_quickstubs.cpp:26818 

0 	xul.dll 	nsTArray<ObserverRef,nsTArrayDefaultAllocator>::AppendElements<ObserverRef> 	obj-firefox/dist/include/nsTArray.h:773
1 	xul.dll 	nsObserverList::FillObserverArray 	xpcom/ds/nsObserverList.cpp:102
2 	xul.dll 	SearchTable 	obj-firefox/xpcom/build/pldhash.c:439
3 	xul.dll 	xul.dll@0x65c9f 	
4 	xul.dll 	nsHttpChannel::AsyncOpen 	netwerk/protocol/http/nsHttpChannel.cpp:3652
5 	xul.dll 	imgLoader::LoadImage 	modules/libpr0n/src/imgLoader.cpp:1659
6 	xul.dll 	nsLoadGroup::AddRef 	netwerk/base/src/nsLoadGroup.cpp:204
7 	xul.dll 	nsImageBoxFrame::UpdateImage 	layout/xul/base/src/nsImageBoxFrame.cpp:271
8 	xul.dll 	nsFrame::Init 	layout/generic/nsFrame.cpp:372
...

0 	xul.dll 	nsTArray<ObserverRef,nsTArrayDefaultAllocator>::AppendElements<ObserverRef> 	obj-firefox/dist/include/nsTArray.h:773
1 	xul.dll 	nsObserverList::FillObserverArray 	xpcom/ds/nsObserverList.cpp:102
2 	xul.dll 	SearchTable 	obj-firefox/xpcom/build/pldhash.c:439
3 	xul.dll 	PL_DHashTableOperate 	obj-firefox/xpcom/build/pldhash.c:625
4 	xul.dll 	nsObserverService::NotifyObservers 	xpcom/ds/nsObserverService.cpp:182
5 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
6 	nspr4.dll 	PR_EnterMonitor 	nsprpub/pr/src/threads/prmon.c:99
7 		@0x9335bf 	
8 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
...

0 	xul.dll 	nsTArray<ObserverRef,nsTArrayDefaultAllocator>::AppendElements<ObserverRef> 	obj-firefox/dist/include/nsTArray.h:773
1 	xul.dll 	nsObserverList::FillObserverArray 	xpcom/ds/nsObserverList.cpp:102
2 	xul.dll 	SearchTable 	obj-firefox/xpcom/build/pldhash.c:472
3 	xul.dll 	xul.dll@0x65c9f 	
4 	xul.dll 	nsWindowWatcher::OpenWindow 	embedding/components/windowwatcher/src/nsWindowWatcher.cpp:418
5 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
6 	xul.dll 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1610
7 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4727
8 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:716 
...

More reports at:
https://crash-stats.mozilla.com/report/list?product=Firefox&signature=nsTArray%3CObserverRef%2C%20nsTArrayDefaultAllocator%3E%3A%3AAppendElements%3CObserverRef%3E%28ObserverRef%20const*%2C%20unsigned%20int%29%20|%20nsObserverList%3A%3AFillObserverArray%28nsCOMArray%3CnsIObserver%3E%26%29
This is the #1 topcrasher in 5.0b2.
looking at a sample of 129 reports from yesterday here are the top addons that appear in those reports

 
 100 {B7082FAA-CB62-4872-9106-E42DD88EDE45}      3.3.1

  81 http://addons.mozilla.org/en-US/firefox/addon/15003" Add-on Compatibility Reporter
   0.8.3

  76 http://addons.mozilla.org/en-US/firefox/addon/13661" Test Pilot 1.1.1
  56 http://addons.mozilla.org/en-US/firefox/addon/1865" Adblock Plus 1.3.7
  48 href=""     4.4
  46 {972ce4c6-7e08-4474-a285-3208198ce6fd}      4.0.1
  44 {972ce4c6-7e08-4474-a285-3208198ce6fd}      5.0
  38 {CAFEEFAC-0016-0000-0024-ABCDEFFEDCBA}      6.0.24

  36 http://addons.mozilla.org/en-US/firefox/addon/9449" Microsoft .NET Framework Assistant 1.2.1

  35 href="" 3.3.3.2
  34 {ABDE892B-13A8-4d1b-88E6-365A6E755758}  14.0.3
  28 http://addons.mozilla.org/en-US/firefox/addon/2032" Yahoo! Toolbar 2.3.5.20110120033202
  27 NO_ADDONS_FOUND
  26 {D4DD63FA-01E4-46a7-B6B1-EDAB7D6AD389}      0.9.8
  25 ""      1.0
  21 http://addons.mozilla.org/en-US/firefox/addon/10900" Personas Plus  1.6.2
  21 {CAFEEFAC-0016-0000-0022-ABCDEFFEDCBA}      6.0.22
  20 http://addons.mozilla.org/en-US/firefox/addon/7661" Read It Later  2.1.1
  20 http://addons.mozilla.org/en-US/firefox/addon/4693" 404-Error ? 1.3
  20 {bf7380fa-e3b4-4db2-af3e-9d8783a45bfc}      3.3.3.2
  20 {D2A6A719-7CBC-4594-85FD-C36AD881424F}     4.5.24
  19 {CAFEEFAC-0016-0000-0023-ABCDEFFEDCBA}      6.0.23
  17 http://addons.mozilla.org/en-US/firefox/addon/8879" FoxTab  1.4.2b
  15 http://addons.mozilla.org/en-US/firefox/addon/4925" AutoPager 0.6.2.8
  15 {CE6E6E3B-84DD-4cac-9F63-8D2AE4F30A4B}</td      3.2
reading labs mail I see that test pilot, and personas plus  got mail from the compat checker that says they were detected as compatible like this:

Dear add-on author,

Good news! Our automated tests did not detect any compatibility issues with your add-on Personas Plus and Firefox 5. We've updated your add-on's compatibility to work with Firefox 5.* so that our beta users can begin using your add-on. Firefox 5 beta was released earlier today.

You can view the results of our compatibility check here: https://addons.mozilla.org/developers/addon/personas-plus/validation-result/24646

rainbow, labkit also got similar mail.

firefox sync 1.7 and open web apps 0.1 got messsages indicating incompatibilty like this:

While testing add-ons for compatibility with the upcoming release of Firefox 5, we detected some potential compatibility issues with your add-on Open Web Apps for Firefox. You can view these results here: https://addons.mozilla.org/developers/addon/open-web-apps-for-firefox/validation-result/24721

Because of these issues, we were not able to automatically mark your add-on as compatible with Firefox 5. Please look into these issues and upload a new version if necessary. If you've tested your add-on and no changes are required, you can update your compatibility to Firefox 5.* here: https://addons.mozilla.org/developers/addon/287764/versions/410385
(In reply to comment #2) 
>  100 {B7082FAA-CB62-4872-9106-E42DD88EDE45}      3.3.1
It is McAfee Site Advisor.
kev, can you check with McAfee to see if they know of any compat/crash problems with firefox 5.0?   we probably need to check out all the AV products.
this is a by-product of revving binary components, I suspect. I've pinged the SiteAdvisor team and other AV orgs to let them know of the need to recompile and support multiple versions of Firefox, but I'll reach out to them specifically. I fully expect this is going to be an issue with a number of third-party distributed (e.g. non-AMO) addons, especially those that incorporate binary components. A six-week release cadence plus the need to supply multiple binary components to support every release is going to make this crop up a lot until we can get JS Ctypes adoption up (but that is opinion only).
Is McAfee Site Advisor marking itself as 5.x compatible?
If those people all have Add-on Compatibility Reporter installed, that one deactivates compat checking and so it doesn't matter if they have marked it compatible, it just will be enabled.

I wonder if we detect a number of startup crashes in a row if we should just launch into safe mode by default... Do we have a bug on that?
I should have taken a closer look at comment #2, as it states that
1) not all but ~2/3 of all crashes have the Add-on Compatibility Reporter installed, which can play into this, and
2) More people that that (almost 5/6) have McAfee Site Advisor, which might mean that it actually does mark itself compatible with 5, which would be a candidate for explaining even more of the problems.
Better stack:
>	xul.dll!nsTArray<ObserverRef,nsTArrayDefaultAllocator>::AppendElements<ObserverRef>(array=0x05695228, arrayLen=0x00000002)  Line 773	C++
 	xul.dll!nsObserverList::FillObserverArray(aArray={...})  Line 104	C++
 	xul.dll!SearchTable(table=0x0068b1cc, key=0x6ec17a94, keyHash=0x903c5336, op=PL_DHASH_LOOKUP)  Line 439	C
 	xul.dll!PL_DHashTableOperate(table=0x00000000, key=0x00000000, op=0x0900d790)  Line 625	C
 	xul.dll!nsObserverService::NotifyObservers(aSubject=0x0900d790, aTopic=0x6ec17a94, someData=0x00000000)  Line 182	C++
 	xul.dll!nsHttpHandler::NotifyObservers(chan=0x0900d790, event=0x6ec17a94)  Line 536	C++
 	xul.dll!nsHttpChannel::AsyncOpen(listener=0x093c1a00, context=0x00000000)  Line 3657	C++
 	xul.dll!nsURILoader::OpenURI(channel=0x093c1a00, aIsContentPreferred=0x00000000, aWindowContext=0x06367a18)  Line 866	C++
 	xul.dll!nsDocShell::DoChannelLoad(aChannel=0x00000003, aURILoader=0x06077570, aBypassClassifier=0x00000000)  Line 9048	C++
 	xul.dll!nsDocShell::DoURILoad(aURI=0x092ef240, aReferrerURI=0x00000000, aSendReferrer=0x00000001, aOwner=0x00000000, aTypeHint=0x00000000, aPostData=0x00000000, aHeadersData=0x00000000, aFirstParty=0x00000001, aDocShell=0x00000000, aRequest=0x0045bfa4, aIsNewWindowTarget=0x00000000, aBypassClassifier=0x00000000, aForceAllowCookies=0x00000000)  Line 8890	C++
 	xul.dll!nsDocShell::InternalLoad(aURI=0x6e1b20cb, aReferrer=0x6e1b20e1, aOwner=0x09131aa0, aFlags=0x06367a98, aWindowTarget=0x00000000, aTypeHint=0x0045c088, aPostData=0x03d0b510, aHeadersData=0x00000000, aLoadType=0x00000000, aSHEntry=0x00682ac0, aFirstParty=0xd671fe07, aDocShell=0x6e215310, aRequest=0x06367a98)  Line 8555	C++
 	nspr4.dll!PR_ExitMonitor(mon=)  Line 135	C
 	xul.dll!nsDocShell::LoadURI(aURI=0x067c5550, aLoadFlags=0x00000000, aReferringURI=0x00000000, aPostStream=0x00000000, aHeaderStream=0x00000000)  Line 3731	C++
 	xul.dll!NS_InvokeByIndex_P(that=0x06367aa4, methodIndex=0x00000008, paramCount=0x00000005, params=0x0045c278)  Line 103	C++
 	xul.dll!XPC_WN_CallMethod(cx=0x055887a0, argc=0x00000005, vp=0x04b102a8)  Line 1610	C++
 	mozjs.dll!js::Interpret(cx=0x00000000, entryFrame=0x04b10038, inlineCallCount=0x00000006, interpMode=JSINTERP_NORMAL)  Line 4727	C++
 	mozjs.dll!js::Invoke(cx=0x055887a0, argsRef={...}, flags=0x00000000)  Line 716	C++
 	mozjs.dll!JS_CallFunctionValue(cx=0x055887a0, obj=0x05fddb90, fval=0xffff000707857b60, argc=0x00000001, argv=0x093c2010, rval=0x0045cdc0)  Line 5153	C++
 	xul.dll!nsJSContext::CallEventHandler(aTarget=0x04606a50, aScope=0x05fddb90, aHandler=0x07857b60, aargv=0x063f87a0, arv=0x0045ce70)  Line 1904	C++
 	xul.dll!nsJSEventListener::HandleEvent(aEvent=0x07ae41f0)  Line 226	C++
 	xul.dll!nsEventListenerManager::HandleEventSubType(aListenerStruct=0x00000000, aListener=0x00000000, aDOMEvent=0x07ae41f0, aCurrentTarget=0x04606a60, aPhaseFlags=0x00000000, aPusher=0x0045d104)  Line 1136	C++
 	xul.dll!nsEventListenerManager::HandleEventInternal(aPresContext=0x067c5400, aEvent=0x067cc800, aDOMEvent=0x6eb30c98, aCurrentTarget=0x0045d118, aFlags=0x04606a60, aEventStatus=0x00000006, aPusher=0x0045d11c)  Line 1233	C++
 	xul.dll!NS_IsMainThread_P()  Line 138	C++
 	xul.dll!nsEventDispatcher::Dispatch(aTarget=, aPresContext=, aEvent=, aDOMEvent=, aEventStatus=, aCallback=, aTargets=)  Line 650	C++
 	xul.dll!DocumentViewerImpl::LoadComplete(aStatus=0x805d0021)  Line 1058	C++
 	xul.dll!nsDocShell::EndPageLoad(aProgress=0x06363814, aChannel=0x067dc280, aStatus=0x805d0021)  Line 6065	C++
 	xul.dll!nsCOMPtr_base::assign_from_qi(qi={...}, iid={...})  Line 96	C++
 	xul.dll!nsDocShell::OnStateChange(aProgress=0x06367a14, aRequest=0x6e3649de, aStateFlags=0x0927d6c0, aStatus=0x00000003)  Line 5918	C++
 	00000003()	
 	xul.dll!PrepareAndDispatch(self=0x06363814, methodIndex=0x06363814, args=0x067dc280, stackBytesToPop=0x067dc280)  Line 114	C++
 	xul.dll!nsDocLoader::FireOnStateChange(aProgress=0x06363814, aRequest=0x067dc280, aStateFlags=0x00020010, aStatus=0x805d0021)  Line 1339	C++
 	xul.dll!nsDocLoader::doStopDocumentLoad(request=0x067dc280, aStatus=0x805d0021)  Line 958	C++
 	xul.dll!nsDocLoader::DocLoaderIsEmpty(aFlushLayout=)  Line 825	C++
 	xul.dll!nsDocLoader::ChildDoneWithOnload(aChild=0x06367a00)  Line 204	C++
 	xul.dll!nsDocLoader::DocLoaderIsEmpty(aFlushLayout=0x00000001)  Line 829	C++
 	xul.dll!nsDocLoader::OnStopRequest(aRequest=0x09223280, aCtxt=0x00000000, aStatus=0x00000000)  Line 707	C++
 	xul.dll!nsLoadGroup::RemoveRequest(request=0x06367a04, ctxt=0x00000000, aStatus=0x00000000)  Line 680	C++
 	xul.dll!nsDocument::DoUnblockOnload()  Line 7374	C++
 	xul.dll!nsDocument::UnblockOnload(aFireSync=0x00000001)  Line 7315	C++
 	xul.dll!nsDocument::DispatchContentLoadedEvents()  Line 4240	C++
 	xul.dll!nsRunnableMethodImpl<void (__thiscall nsDocument::*)(void),1>::Run()  Line 345	C++

We're crashing in AssignRange; it kinda apppears as if the source nsTArray is corrupted. I don't yet know how that could happen; we prevent non-mainthread access to the observer service, so it's probably not a threading issue.

I'm not sure how this could be a byproduct of revving binary components, since these components would simply fail to load, and no JS should be able to cause this kind of crash.
I can reproduce this in the QA lab on the Windows 7 machine using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0, which is B2.

STR:
1. Install a trial version of Site Advisor from http://www.siteadvisor.com/
2. Install the beta. Extension is marked as not compatible.
3. Install https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter/.
4. After restart I crash, and stay in a crash death cycle until I create a new profile.

Site Advisor is Version 3.3.1
Keywords: reproducible
about 1/3rd of crash reporters on this signature are proving e-mail addresses, so mailing them to turn compat checking back on is the way to avoid the crash and get back on the beta.  they could probably set this, or turn off the compatibility reporter from 4.0.1 or another firefox install.

We need to get these users back on their feet to make sure that what Site Advisor users that we do have stay in the beta pool for future betas, and we need to get McAfee to fix this quickly.  Kev, do they know about this, and/or have a date?
(In reply to comment #10)
> I'm not sure how this could be a byproduct of revving binary components,
> since these components would simply fail to load, and no JS should be able
> to cause this kind of crash.

Ok, wasn't sure if turning compat checks off affected components as well. Thanks for the clarification.

(In reply to comment #12)
> We need to get these users back on their feet to make sure that what Site
> Advisor users that we do have stay in the beta pool for future betas, and we
> need to get McAfee to fix this quickly.  Kev, do they know about this,
> and/or have a date?

We still need to establish a root cause, too, because from what Benjamin says this shouldn't be happening. I've contacted the Site Advisor PM, and he's looking into it. I'll circle around within 48hrs unless they comment in the bug directly (they have it).
(In reply to comment #13)
> Ok, wasn't sure if turning compat checks off affected components as well.
> Thanks for the clarification.

It affects everything packaged in an add-on. If the add-on contains binary components, it affects them as well. (Just as a general info.)

I think I really should make sure we have a bug on file on paragraph 2 of comment #8 (i.e. after some number of crashes in a row we should start in safe mode by default, which has add-ons disabled and allows us to update blocklists and the app if needed, I hope).
(In reply to comment #14)
> I think I really should make sure we have a bug on file on paragraph 2 of
> comment #8 (i.e. after some number of crashes in a row we should start in
> safe mode by default, which has add-ons disabled and allows us to update
> blocklists and the app if needed, I hope).

Bug 502958 seems to be that, just as a note.
Technical details: the siteadvisor component DLL is causing this problem. We're attempting to load it with this stack:

>	xul.dll!nsObserverService::AddObserver(nsIObserver * anObserver=0x037612b8, const char * aTopic=0x0086cb10, int ownsWeak=0)  Line 128	C++
 	McFFPlg.dll!0084619d() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for McFFPlg.dll]	
 	McFFPlg.dll!00867b2d() 	
 	McFFPlg.dll!00851e03() 	
 	McFFPlg.dll!00851e8e() 	
 	McFFPlg.dll!0084ea56() 	
 	McFFPlg.dll!0084eb70() 	
 	McFFPlg.dll!0084ec2b() 	
 	ntdll.dll!_LdrpCallInitRoutine@16()  + 0x14 bytes	
 	ntdll.dll!_LdrpRunInitializeRoutines@4()  - 0x7e1 bytes	
 	ntdll.dll!_LdrpLoadDll@24()  - 0x20d9 bytes	
 	ntdll.dll!_LdrLoadDll@16()  + 0x116 bytes	
 	firefox.exe!patched_LdrLoadDll(wchar_t * filePath=0x76e5a660, unsigned long * flags=0xc8e705cc, _UNICODE_STRING * moduleFileName=0x76db96a0, void * * handle=0x01260848)  Line 212	C++
 	kernel32.dll!_BaseComputeProcessDllPath@8()  + 0x3995b bytes	
 	nspr4.dll!pr_LoadLibraryByPathname(const char * name=0x00000000, int flags=32769)  Line 759 + 0x19 bytes	C
 	nspr4.dll!PR_LoadLibraryWithFlags(PRLibSpec libSpec={...}, int flags=0)  Line 451 + 0x9 bytes	C
 	xul.dll!nsLocalFile::Load(PRLibrary * * _retval=0x0020e88c)  Line 1812 + 0x1c bytes	C++
 	xul.dll!nsNativeModuleLoader::LoadModule(nsILocalFile * aFile=0x0342fc40)  Line 165	C++
 	xul.dll!nsCOMPtr_base::assign_from_qi(nsQueryInterface qi={...}, const nsID & iid={...})  Line 98 + 0x8 bytes	C++
 	xul.dll!nsComponentManagerImpl::ManifestBinaryComponent(nsComponentManagerImpl::ManifestProcessingContext & cx={...}, int lineno=9, char * const * argv=0x0342fc40)  Line 740	C++

This happens while we are loading the DLL to get "NSModule" from it and check the version numbers. However, simply the act of loading is causing the DLL to run code, probably through DllMain or a static initializer. There's not a lot we can do to prevent this.

We don't actually load it as an XPCOM component.

SiteAdvisor needs to stop using DllMain or a static initializer to run code here.
Summary: Start-up crash [@ nsTArray<ObserverRef, nsTArrayDefaultAllocator>::AppendElements<ObserverRef>(ObserverRef const*, unsigned int) | nsObserverList::FillObserverArray(nsCOMArray<nsIObserver>&) ] → Start-up crash with incompatible version of McAfee SiteAdvisor [@ nsTArray<ObserverRef, nsTArrayDefaultAllocator>::AppendElements<ObserverRef>(ObserverRef const*, unsigned int) | nsObserverList::FillObserverArray(nsCOMArray<nsIObserver>&) ]
As a workaround, we should hardblock this version of siteadvisor for FF5.
who can do the blocklist patch?
(In reply to comment #18)
> who can do the blocklist patch?

That would be Fligtar or one of his minions, I believe. 

Fligtar, can you do that for us, please? Also, should we clone this bug for a blocklist resolution or use this one?
Bug 660111 created to track the blocklist request.

(In reply to comment #19)
If the blocklist got us what we need, we can probably stop tracking this bug. What do these crashes look like now?
(In reply to comment #21)
> If the blocklist got us what we need, we can probably stop tracking this
> bug. What do these crashes look like now?
It is now only #26 top crasher in 5.0b2 over the last 3 days.
So the tracking may be removed.
Nevertheless, McAfee Site Advisor's hard blocklist seems to be by-passed (except if correlations display disabled extensions) and there are still crashes with other extensions.
    44% (28/64) vs.   0% (37/22621) {B7082FAA-CB62-4872-9106-E42DD88EDE45} (McAfee SiteAdvisor, http://www.siteadvisor.com/) (3.3.1)
     39% (25/64) vs.   2% (368/22621) compatibility@addons.mozilla.org
         20% (13/64) vs.   0% (42/22621) 0.8.3
         19% (12/64) vs.   1% (325/22621) 0.8.4
     31% (20/64) vs.   2% (500/22621) {1018e4d6-728f-4b20-ad56-37578a4de76b} (Flagfox, https://addons.mozilla.org/addon/5791)
          9% (6/64) vs.   0% (50/22621) 4.1.2
         22% (14/64) vs.   2% (421/22621) 4.1.3
     19% (12/64) vs.   2% (379/22621) {635abd67-4fe9-1b23-4f01-e679fa7484c1} (Yahoo! Toolbar, https://addons.mozilla.org/addon/2032)
          3% (2/64) vs.   0% (2/22621) 2.3.3.20101115011850
         16% (10/64) vs.   2% (366/22621) 2.3.5.20110120033202
          0% (0/64) vs.   0% (10/22621) 2.3.6.20110307083656
     16% (10/64) vs.   1% (270/22621) {ABDE892B-13A8-4d1b-88E6-365A6E755758}
          2% (1/64) vs.   0% (1/22621) 1.1.2
         11% (7/64) vs.   0% (102/22621) 14.0.2
          3% (2/64) vs.   0% (79/22621) 14.0.3
     14% (9/64) vs.   0% (10/22621) wonderpage@wonderpage.com (1.6)
     14% (9/64) vs.   0% (13/22621) {9D23D0AA-D8F5-11DA-B3FC-0928ABF316DD} (CookieSafe, https://addons.mozilla.org/addon/2497) (3.0.5)
     14% (9/64) vs.   0% (22/22621) amin.eft_PhProxy@gmail.com (Phzilla (formerly PhProxy - InBasic), https://addons.mozilla.org/addon/3239) (4.0.1C)
     14% (9/64) vs.   0% (46/22621) feedly@devhd (Feedly, https://addons.mozilla.org/addon/8538)
         14% (9/64) vs.   0% (42/22621) 5.5
          0% (0/64) vs.   0% (4/22621) 5.6
     14% (9/64) vs.   1% (229/22621) {AE93811A-5C9A-4d34-8462-F7B864FC4696} (StumbleUpon, https://addons.mozilla.org/addon/138)
         14% (9/64) vs.   1% (227/22621) 3.91
Summary: Start-up crash with incompatible version of McAfee SiteAdvisor [@ nsTArray<ObserverRef, nsTArrayDefaultAllocator>::AppendElements<ObserverRef>(ObserverRef const*, unsigned int) | nsObserverList::FillObserverArray(nsCOMArray<nsIObserver>&) ] → Start-up crash with incompatible version of some extensions [@ nsTArray<ObserverRef, nsTArrayDefaultAllocator>::AppendElements<ObserverRef>(ObserverRef const*, unsigned int) | nsObserverList::FillObserverArray(nsCOMArray<nsIObserver>&) ]
(In reply to comment #22)
> (In reply to comment #21)
> > If the blocklist got us what we need, we can probably stop tracking this
> > bug. What do these crashes look like now?
> It is now only #26 top crasher in 5.0b2 over the last 3 days.
> So the tracking may be removed.
> Nevertheless, McAfee Site Advisor's hard blocklist seems to be by-passed
> (except if correlations display disabled extensions) and there are still
> crashes with other extensions.
>     44% (28/64) vs.   0% (37/22621) {B7082FAA-CB62-4872-9106-E42DD88EDE45}
> (McAfee SiteAdvisor, http://www.siteadvisor.com/) (3.3.1)
>      39% (25/64) vs.   2% (368/22621) compatibility@addons.mozilla.org

this addon, the compatibility checker, turns off addon version checking so that will be a contributor to crashes here.  maybe the compatibility checker could be modified to have a 'allow list' to allow checking for versions that are known to be problematic and need checking turned back on.

even a few days ago it seems these crashes were dominated by people with checking turned off.

stats for may 26
  28 [unknown]
   5 checked
 234 not

 may 27.
  32 [unknown]
   5 checked
 159 not
(In reply to comment #23)
> this addon, the compatibility checker, turns off addon version checking so
> that will be a contributor to crashes here.

That's what we noted already. But this disabling of compatibility checking doesn't disable the blocklist, it still applies and works, right? Otherwise I'd consider that a grave bug/problem.
Crash Signature: [@ nsTArray<ObserverRef, nsTArrayDefaultAllocator>::AppendElements<ObserverRef>(ObserverRef const*, unsigned int) | nsObserverList::FillObserverArray(nsCOMArray<nsIObserver>&) ]
131 crashes in the last week using the latest Firefox 5 beta, 20110608151458.
It's now correlated in 8.0.1 with some AV and Russian extensions:
     41% (26/63) vs.   1% (653/48832) {4ED1F68A-5463-4931-9384-8FFF5ED91D92} (McAfee SiteAdvisor)
     37% (23/63) vs.   6% (2955/48832) yasearch@yandex.ru (Yandex.Bar, https://addons.mozilla.org/addon/3495)
     30% (19/63) vs.   6% (2772/48832) {37964A3C-4EE8-47b1-8321-34DE2C39BA4D} (Спутник @Mail.Ru)
     13% (8/63) vs.   0% (188/48832) KavAntiBanner@Kaspersky.ru
     13% (8/63) vs.   1% (265/48832) virtualKeyboard@kaspersky.ru
     13% (8/63) vs.   1% (297/48832) {D19CA586-DD6C-4a0a-96F8-14644F340D60} (McAfee ScriptScan for Firefox)
     13% (8/63) vs.   1% (299/48832) linkfilter@kaspersky.ru
     10% (6/63) vs.   1% (660/48832) {82AF8DCA-6DE9-405D-BD5E-43525BDAD38A} (Skype extension)
Firefox 10 Crash - bp-e11f0b87-4990-4349-b420-d25b12120206
Version: 2.0 Branch → unspecified
(In reply to Scoobidiver from comment #28)
> It's now correlated in 8.0.1 with some AV and Russian extensions:
>      41% (26/63) vs.   1% (653/48832) {4ED1F68A-5463-4931-9384-8FFF5ED91D92}
> (McAfee SiteAdvisor)
>      37% (23/63) vs.   6% (2955/48832) yasearch@yandex.ru (Yandex.Bar,
> https://addons.mozilla.org/addon/3495)
>      30% (19/63) vs.   6% (2772/48832)
> {37964A3C-4EE8-47b1-8321-34DE2C39BA4D} (Спутник @Mail.Ru)
>      13% (8/63) vs.   0% (188/48832) KavAntiBanner@Kaspersky.ru
>      13% (8/63) vs.   1% (265/48832) virtualKeyboard@kaspersky.ru
>      13% (8/63) vs.   1% (297/48832) {D19CA586-DD6C-4a0a-96F8-14644F340D60}
> (McAfee ScriptScan for Firefox)
>      13% (8/63) vs.   1% (299/48832) linkfilter@kaspersky.ru
>      10% (6/63) vs.   1% (660/48832) {82AF8DCA-6DE9-405D-BD5E-43525BDAD38A}
> (Skype extension)

hey scoobie does it occur when disable Kaspersky addon?
i think Mcafee addon are culprit for this issue!
(In reply to Swarnava Sengupta (:Swarnava) from comment #30)
> hey scoobie does it occur when disable Kaspersky addon?
I filed this bug from crash stats.

(In reply to Swarnava Sengupta (:Swarnava) from comment #31)
> i think Mcafee addon are culprit for this issue!
59% of users don't have this add-on installed.
Crash Signature: [@ nsTArray<ObserverRef, nsTArrayDefaultAllocator>::AppendElements<ObserverRef>(ObserverRef const*, unsigned int) | nsObserverList::FillObserverArray(nsCOMArray<nsIObserver>&) ] → [@ nsTArray<ObserverRef, nsTArrayDefaultAllocator>::AppendElements<ObserverRef>(ObserverRef const*, unsigned int) | nsObserverList::FillObserverArray(nsCOMArray<nsIObserver>&) ] [@ nsTArray<T>::AppendElements<T> | nsObserverList::FillObserverArray ]
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.