Closed Bug 658780 Opened 13 years ago Closed 6 years ago

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

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox5 + ---

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, regression, reproducible)

Crash Data

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?
Blocks: 660111
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: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.