Closed Bug 1505094 Opened 6 years ago Closed 6 years ago

High proportion of out-of-memory crashes for users with Norton extensions

Categories

(External Software Affecting Firefox :: Other, defect)

x86
Windows
defect
Not set
critical

Tracking

(firefox-esr60- wontfix, firefox63+ wontfix, firefox64 wontfix, firefox65 fixed, firefox66 fixed)

RESOLVED FIXED
Tracking Status
firefox-esr60 - wontfix
firefox63 + wontfix
firefox64 --- wontfix
firefox65 --- fixed
firefox66 --- fixed

People

(Reporter: philipp, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is
report bp-787a12a4-05bf-4106-be5a-6006b0181106.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll js::AutoEnterOOMUnsafeRegion::crash js/src/vm/JSContext.cpp:1577
1 xul.dll js::AutoEnterOOMUnsafeRegion::crash js/src/vm/JSContext.cpp:1591
2 xul.dll js::gc::AllocateCellInGC js/src/gc/Allocator.cpp:364
3 xul.dll js::TenuringTracer::moveToTenuredSlow js/src/gc/Marking.cpp:2971
4 xul.dll js::TenuringTracer::traverse<JSObject> js/src/gc/Marking.cpp:2677
5 xul.dll js::DispatchTyped<js::TenuringTraversalFunctor<JS::Value>, js::TenuringTracer*> js/public/Value.h:1441
6 xul.dll js::gc::StoreBuffer::SlotsEdge::trace js/src/gc/Marking.cpp:2760
7 xul.dll js::Nursery::doCollection js/src/gc/Nursery.cpp:899
8 xul.dll js::Nursery::collect js/src/gc/Nursery.cpp:755
9 xul.dll js::gc::GCRuntime::minorGC js/src/gc/GC.cpp:7975

=============================================================

i've discovered this crash pattern when i looked at the content crash signature from bug 1472062 that's increasing in firefox 63. correlations there show:
(22.20% in signature vs 03.75% overall) Addon "Norton Safe Web" = true

when just looking at crash reports which have that addon installed, the [@ OOM |...js::gc::AllocateCellInGC] and [@ OOM | small] signatures account to close to 60% of tab crashes for them (and over 75% when narrowing it down to just 32bit installations):
https://crash-stats.mozilla.com/search/?addons=~nortonsafeweb%40symantec.com&product=Firefox&version=63.0.1&version=63.0&process_type=content&date=%3E%3D2018-10-01&_facets=signature&_facets=platform_pretty_version&_facets=addons&_facets=cpu_arch#facet-signature

this indicates that their extension or main AV software hooking into the browser may be prone to some memory leaks. do we have some contacts at symantec to reach out to about this issue?
We have reached out to Symantec and they are investigating.
Wontfix for 63 since 64 is 2 weeks away.
I have suffered this bug a couple of times. Although I don't use Norton, :philipp mentioned possible memory leaks so I've decided to add a comment to this report rather than create a new one as my STR could support that. I don't have a repeatable STR but in cases of crashes the steps have been very similar.

Here are some of my bug reports:
https://crash-stats.mozilla.com/report/index/429e9cb1-e317-4757-bfd0-82dbe0181211
https://crash-stats.mozilla.com/report/index/cfa5da5a-9fb7-4abf-a702-960ab0181128
https://crash-stats.mozilla.com/report/index/7317f49c-08ba-4e24-a72f-723940181128

I have seen this crash while running in the background some VBA/Excel scripts (yes, I know..) that process large data arrays and consume a lot of memory. With these scripts and a youtube video playing I might start to suffer some skipping of the youtube video before the tab crashes. After trying to restore the tab, Firefox itself will crash completely. After that win10 might be unrecoverable (all usability/video lost) depending upon whether the script finishes in a timely manner. (In these cases I wasn't watching or observing RAM usage).
Adding 66 as affected. This is a top content crash on 64 and 65b4.
This is fairly high already in 64 - will reach out again to our contacts.
You need to log in before you can comment on or make changes to this bug.