Crash in [@ fcagff64.dll | arena_t::GetNonFullBinRun | Allocator<T>::malloc | Allocator<T>::malloc | replace_malloc] (McAfee DLP)
Categories
(External Software Affecting Firefox :: Other, defect, P1)
Tracking
(firefox86 fixed, firefox87 fixed)
People
(Reporter: sg, Assigned: toshi)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Crash Data
Attachments
(2 files)
1.67 KB,
text/plain
|
Details | |
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
This bug is for crash report bp-6f44326d-0797-4ccc-b1d1-dbb220200428.
Top 10 frames of crashing thread:
0 fcagff64.dll fcagff64.dll@0x3774b9
1 fcagff64.dll fcagff64.dll@0xc7354
2 fcagff64.dll fcagff64.dll@0xd35b8
3 fcagff64.dll fcagff64.dll@0x201be
4 mozglue.dll arena_t::GetNonFullBinRun memory/build/mozjemalloc.cpp:2715
5 mozglue.dll static Allocator<MozJemallocBase>::malloc memory/build/malloc_decls.h:51
6 mozglue.dll static Allocator<MozJemallocBase>::malloc memory/build/malloc_decls.h:51
7 mozglue.dll replace_malloc memory/replace/phc/PHC.cpp:1122
8 mozglue.dll moz_xmalloc memory/mozalloc/mozalloc.cpp:52
9 @0x24162f4257f
Crashes starting with Nightly build 20200415215103 in some DLL from McAfee. Bug 1420872 also reported similar crashes in that DLL a while ago. Not sure if this is actionable.
Comment 1•5 years ago
|
||
This sounds more like it is some external software interfering with Firefox rather than an issue with our allocator.
Comment 2•5 years ago
|
||
The DLL version is from last year so it could be some leftover piece of a McAfee AV product the user has uninstalled or is not updating. All the crashes seem to be coming from the same machine.
Comment 3•5 years ago
•
|
||
All the crashes seem to be coming from the same machine.
I see at least 2 different machines in the crash report. Toshi pointed out that if you filter the 64 from the DLL signature there's a lot more crashers.
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
fcagff64.dll (and fcagff.dll for 32bit) is a part of McAfee Data Loss Prevention (DLP) which is not downloadable in public. I tried McAfee Total Protection, but it did not include fcagff64.dll.
The stack trace in the crash reports is not accurate. The frames of mozglue's functinos are just garbage data in the stack memory. What I can see is fcagff64's code was invoked from xul!mozilla::net::nsHttpConnection::OnReadSegment
. So this crash is always from the browser process though the module is injected into the tab process, too.
I extracted the list of the module's versions from the last 30 days crashes. On the other hand, the third-party-module ping indicates there are newer versions such as 11.5.0.60 or 11.5.0.53, but I'm not sure whether this problem has been fixed on McAfee side because the number is small.
Version (Crash count)
11.5.0.44 (1)
11.4.0.45 (376)
11.3.26.4 (1)
11.3.2.8 (235)
11.3.0.17 (193)
11.2.0.6 (15)
11.2.0.14 (77)
11.1.100.23 (171)
11.1.0.61 (16)
11.0.700.9 (4)
11.0.700.18 (20)
11.0.600.7 (9)
11.0.500.58 (6)
11.0.405.4 (1)
11.0.402.4 (1)
11.0.400.15 (7)
11.0.300.84 (35)
11.0.200.100 (11)
11.0.2.3 (5)
11.0.150.1 (4)
11.0.130.24 (2)
10.0.500.19 (1)
10.0.350.1 (1)
10.0.250.9 (1)
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 5•5 years ago
|
||
Added another signature with 32bit version of fcagff.dll, which was involved from somewhere around xul!mozilla::net::nsHttpConnection::OnReadSegment
, too.
Assignee | ||
Comment 6•5 years ago
|
||
Assignee | ||
Comment 7•5 years ago
|
||
Comment 9•5 years ago
|
||
bugherder |
Comment 10•5 years ago
|
||
Toshi, is that something we want to uplift to 86 or is it OK to let it ride the trains? Thanks
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 11•5 years ago
|
||
(In reply to Pascal Chevrel:pascalc from comment #10)
Toshi, is that something we want to uplift to 86 or is it OK to let it ride the trains? Thanks
The crash volume should be larger than we see because there are more signatures indicating this problem. Let's uplift to 86.
Assignee | ||
Comment 12•5 years ago
|
||
Comment on attachment 9199351 [details]
Bug 1634090 - Block McAfee DLP's module v11.6 or older. r=gcp
Beta/Release Uplift Approval Request
- User impact if declined: Firefox's main process crashes when McAfee DLP is installed.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This is a config-only change, adding McAfee's modules (v11.6 and older) to our blocklist.
- String changes made/needed: None
Comment 13•5 years ago
|
||
Comment on attachment 9199351 [details]
Bug 1634090 - Block McAfee DLP's module v11.6 or older. r=gcp
Approved for 86 beta 3, thanks.
Comment 14•5 years ago
|
||
bugherder uplift |
Comment 15•4 years ago
|
||
There was outreach to McAfee regarding this crash around the 26th of June 2020, but no response was received at the time.
We managed to re-establish contact now and are working to try to resolve the issue.
Assignee | ||
Comment 16•4 years ago
|
||
Adding more signatures to get a more accurate number
Assignee | ||
Updated•4 years ago
|
Comment 17•4 years ago
|
||
As a McAfee user and support hundreds of McAfee users, I am curious to see how much or if the amount of crashes drops. Please share those results here, if you'd be so kind.
Comment 18•4 years ago
|
||
Worcester, do you mean you're seeing this crash with your installations? The block does not apply to Firefox ESR so is it possible you're using that?
We're in contact with McAfee and they said (IIRC) that they didn't get any reports from their customers in the field and so have no real idea where to look, so that's pretty interesting to us, especially if there's a specific use case where it is somewhat reproducible.
Comment 19•4 years ago
|
||
(In reply to Gian-Carlo Pascutto [:gcp] from comment #18)
Worcester, do you mean you're seeing this crash with your installations? The block does not apply to Firefox ESR so is it possible you're using that?
We're in contact with McAfee and they said (IIRC) that they didn't get any reports from their customers in the field and so have no real idea where to look, so that's pretty interesting to us, especially if there's a specific use case where it is somewhat reproducible.
Not this one specifically, but there are always ones with no known cause that raise a question mark. Sorry, wish I could help. Thanks.
Description
•