Closed Bug 521745 Opened 15 years ago Closed 13 years ago

threadsafety problems in McAfee SiteAdvisor extension causing Firefox 3.5.* crashes

Categories

(Plugins Graveyard :: McAfee AV, defect, P2)

Product:
Plugins Graveyard
Component:
McAfee AV
Platform:
x86
Windows XP
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: dbaron, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [crashkill][crashkill-thirdparty])

As I already described in bug 500879 comment 19 and in http://groups.google.com/group/mozilla.dev.platform/msg/5472241d613b1684 the McAfee SiteAdvisor extension, in the 3.0 beta version (but not any of the 2.* versions) accesses main-thread-only objects on other threads, contributing to Firefox 3.5.3 top crashes at the following signatures: nsCycleCollectingAutoRefCnt::decr(nsISupports*) nsEventListenerManager::Release() KiFastSystemCallRet (pure virtual function call) nsPresContext::Release() nsGlobalChromeWindow::Release() nsHTMLDocument::Release() nsJSContext::Release() nsGlobalWindow::Release() nsPurpleBuffer::SelectPointers(GCGraphBuilder&) nsDOMEvent::Release() nsXULDocument::Release() nsTextNode::Release() XPCWrappedNative::InitTearOff(XPCCallContext&, XPCWrappedNativeTearOff*, XPCNativeInterface*, int) etc. I've been in touch with the developers of this extension and they're working on an updated version of their beta with the threadsafety problems fixed (testing using a debug build), but I wanted to file a bug to track the issue.
This 3.0 beta is available on http://beta.mcafee.com/ as part of the McAfee Total Protection 4.0 beta.
I spoke to my contact at McAfee last week, and they said that they rolled out the update to 20% of their users last week, and would roll it out to the rest on Wednesday (i.e., yesterday).
http://people.mozilla.com/crash_analysis/ shows that the report from 10-22 had (for the top crash, nsCycleCollectingAutoRefCnt::decr(nsISupports*)): 25% (439/1728) vs. 5% (4665/99491) McFFPlg.dll 0% (1/1728) vs. 0% (111/99491) 1.0.1.186 0% (0/1728) vs. 0% (9/99491) 1.0.1.200 0% (1/1728) vs. 0% (123/99491) 1.0.1.203 0% (2/1728) vs. 0% (263/99491) 1.0.1.204 0% (0/1728) vs. 0% (22/99491) 1.0.2.155 0% (0/1728) vs. 0% (1/99491) 1.0.2.157 1% (21/1728) vs. 1% (1304/99491) 1.0.2.158 0% (0/1728) vs. 0% (12/99491) 1.6.0.109 0% (0/1728) vs. 0% (6/99491) 2.0.0.284 0% (0/1728) vs. 0% (3/99491) 2.0.0.326 0% (0/1728) vs. 0% (13/99491) 2.0.0.328 0% (1/1728) vs. 0% (1/99491) 3.0.0.449 0% (5/1728) vs. 0% (38/99491) 3.0.0.476 1% (11/1728) vs. 0% (115/99491) 3.0.0.479 10% (177/1728) vs. 1% (1079/99491) 3.0.1.109 12% (214/1728) vs. 1% (1450/99491) 3.0.1.111 0% (6/1728) vs. 0% (115/99491) 3.0.1.112 but for 10-27 it has: 13% (216/1640) vs. 3% (3476/103025) McFFPlg.dll 0% (2/1640) vs. 0% (139/103025) 1.0.1.186 0% (0/1640) vs. 0% (20/103025) 1.0.1.200 0% (4/1640) vs. 0% (132/103025) 1.0.1.203 0% (8/1640) vs. 0% (249/103025) 1.0.1.204 0% (0/1640) vs. 0% (24/103025) 1.0.2.155 1% (19/1640) vs. 1% (1495/103025) 1.0.2.158 0% (0/1640) vs. 0% (7/103025) 1.6.0.109 0% (0/1640) vs. 0% (2/103025) 2.0.0.284 0% (0/1640) vs. 0% (2/103025) 2.0.0.326 0% (0/1640) vs. 0% (8/103025) 2.0.0.328 0% (0/1640) vs. 0% (1/103025) 3.0.0.449 0% (6/1640) vs. 0% (47/103025) 3.0.0.476 1% (15/1640) vs. 0% (125/103025) 3.0.0.479 8% (126/1640) vs. 1% (659/103025) 3.0.1.109 2% (31/1640) vs. 0% (208/103025) 3.0.1.111 0% (5/1640) vs. 0% (358/103025) 3.0.1.112 so I'm guessing that: * 3.0.1.112 is the fixed version * by now, a little more than half their affected users have that version
And the data from 9-29 were: 34% (510/1508) vs. 5% (4667/95088) McFFPlg.dll 0% (0/1508) vs. 0% (96/95088) 1.0.1.186 0% (0/1508) vs. 0% (12/95088) 1.0.1.200 0% (0/1508) vs. 0% (113/95088) 1.0.1.203 0% (1/1508) vs. 0% (208/95088) 1.0.1.204 0% (0/1508) vs. 0% (1/95088) 1.0.2.137 0% (1/1508) vs. 0% (40/95088) 1.0.2.155 0% (0/1508) vs. 0% (1/95088) 1.0.2.157 1% (13/1508) vs. 1% (1103/95088) 1.0.2.158 0% (0/1508) vs. 0% (10/95088) 1.6.0.109 0% (0/1508) vs. 0% (5/95088) 2.0.0.284 0% (0/1508) vs. 0% (8/95088) 2.0.0.328 0% (5/1508) vs. 0% (32/95088) 3.0.0.476 1% (10/1508) vs. 0% (76/95088) 3.0.0.479 0% (0/1508) vs. 0% (2/95088) 3.0.1.108 31% (474/1508) vs. 3% (2912/95088) 3.0.1.109 0% (6/1508) vs. 0% (48/95088) 3.0.1.111
Seeing a drop?
McFFPlg.dll has fallen off the chart for the ...::decr crash; it's still showing up for nsPresContext::Release and nsDOMEvent::Release (maybe it was a bigger share of those originally?)
Whiteboard: [crashkill][crashkill-thirdparty]
Depends on: 637542
We're now tracking such bugs. This doesn't mean it's something we can fix, merely something we hope to be able to point vendors to so they can investigate. This is an automated message.
Assignee: dbaron → nobody
Status: ASSIGNED → UNCONFIRMED
Component: Extension Compatibility → McAfee AV
Ever confirmed: false
Product: Firefox → Plugins
QA Contact: extension.compatibility → mcafee-antivirus
Version: 3.5 Branch → unspecified
Keywords: topcrash
Severity: normal → critical
@Scoobidiver: why is this critical? Is it still a frequently reported crash?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Jorge Villalobos [:jorgev] from comment #8) > @Scoobidiver: why is this critical? Is it still a frequently reported crash? My bad. Firefox crashes are considered as critical whatever their frequency, but the blocklist component doesn't follow this rule, critical seems to be reserved for security issues or high volume crashes. Anyway, McFFPlg32.dll is correlated in low volume to: nsThread::ProcessNextEvent(bool, bool*)|EXCEPTION_ACCESS_VIOLATION_READ (39 crashes) 8% (3/39) vs. 0% (12/146527) NPMcFFPlg32.dll which is #205 browser crasher in 11.0. I close it as workforme.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.