Closed Bug 1196899 Opened 10 years ago Closed 9 years ago

crash in wcscpy_s with Trend Micro Browser Plug-In

Categories

(External Software Affecting Firefox :: Other, defect)

Product:
External Software Affecting Firefox
Component:
Other
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(firefox46blocking wontfix, firefox47+ wontfix, firefox48+ wontfix, firefox49 fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox46 blocking wontfix
firefox47 + wontfix
firefox48 + wontfix
firefox49 --- fixed

People

(Reporter: philipp, Assigned: RyanVM)

References

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is report bp-bad33bde-9cb2-4eff-9460-0305e2150820. ============================================================= Crashing Thread Frame Module Signature Source 0 msvcr110.dll wcscpy_s Ø 1 tmbpffcore.dll tmbpffcore.dll@0x3c43 Ø 2 tmbpffcore.dll tmbpffcore.dll@0x18d2b 3 xul.dll ffi_call_win32 4 xul.dll ffi_call 5 xul.dll js::ctypes::FunctionType::Call js/src/ctypes/CTypes.cpp 6 xul.dll js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp 7 xul.dll js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/proxy/DirectProxyHandler.cpp 8 xul.dll js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/proxy/CrossCompartmentWrapper.cpp 9 xul.dll js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp 10 xul.dll js::jit::InvokeFunction(JSContext*, JS::Handle<JSObject*>, unsigned int, JS::Value*, JS::Value*) js/src/jit/VMFunctions.cpp 11 @0x1fcd34b5 12 xul.dll EnterIon js/src/jit/Ion.cpp 13 xul.dll js::jit::IonCannon(JSContext*, js::RunState&) js/src/jit/Ion.cpp 14 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp 15 xul.dll js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp 16 xul.dll js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/proxy/DirectProxyHandler.cpp 17 xul.dll js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/proxy/CrossCompartmentWrapper.cpp 18 xul.dll js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp 19 xul.dll js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp 20 xul.dll js::jit::DoCallFallback js/src/jit/BaselineIC.cpp 21 @0x1fcd40de 22 @0x1e7efa37 23 @0x1fcd08f0 24 xul.dll EnterBaseline js/src/jit/BaselineJIT.cpp 25 xul.dll XPCConvert::NativeInterface2JSObject(JS::MutableHandle<JS::Value>, nsIXPConnectJSObjectHolder**, xpcObjectHelper&, nsID const*, XPCNativeInterface**, bool, nsresult*) js/xpconnect/src/XPCConvert.cpp 26 xul.dll nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) js/xpconnect/src/XPCWrappedJSClass.cpp This is a windows crash with involvement of a dll injected by the Trend Micro Browser Plug-In and it is #21 at the scoreboard for 40.0.2 at the moment but it has been going on for a bit already. some of the commenters seem to point out that the crash is occurring while they try to load a webpage.
See Also: → 1196905
See Also: → 1196911
I am looking for Trend Micro's contact.
Crash Signature: [@ wcscpy_s] → [@ wcscpy_s] [@ wcsnlen]
Kairo, trend micro asks me that they would like to research mini dump by crash reporter. Could we provide or share it to them?
Flags: needinfo?(kairo)
(In reply to Makoto Kato [:m_kato] from comment #2) > Kairo, trend micro asks me that they would like to research mini dump by > crash reporter. Could we provide or share it to them? We usually can't due to privacy, as raw memory of users is in those dumps. That said, bsmedberg knows the details of how and when we can hand over dumps, so forwarding to him.
Flags: needinfo?(kairo) → needinfo?(benjamin)
A reporter is affected by this crash in bug 1241145.
You can ask individuals experiencing this bug for permission to send their minidump to Trend Micro (such as the person from bug 1241145). Otherwise we cannot share dumps with them, but we could use their symbol files to send them information.
Flags: needinfo?(benjamin)
The reporter of bug 1241145 says his crashes went away after TrendMicro's latest update. Can we close this bug (and bug 1241145) as fixed (by TrendMicro)?
(In reply to Chris Peterson [:cpeterson] from comment #6) > The reporter of bug 1241145 says his crashes went away after TrendMicro's > latest update. Can we close this bug (and bug 1241145) as fixed (by > TrendMicro)? The reporter in bug 1241145 is reporting new crashes since. They also agreed to provide dump information, per https://bugzilla.mozilla.org/show_bug.cgi?id=1241145#c28. Not sure what the process is from here?
Flags: needinfo?(m_kato)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #8) > (In reply to Chris Peterson [:cpeterson] from comment #6) > > The reporter of bug 1241145 says his crashes went away after TrendMicro's > > latest update. Can we close this bug (and bug 1241145) as fixed (by > > TrendMicro)? > > The reporter in bug 1241145 is reporting new crashes since. They also agreed > to provide dump information, per > https://bugzilla.mozilla.org/show_bug.cgi?id=1241145#c28. Not sure what the > process is from here? I will add you to mail thread with trend micro.
Flags: needinfo?(m_kato)
any updates on this in the conversations with trend micro? these crashes are still around in full swing...
One of my QA people was able to reproduce and we sent a minidump to them for analysis. Haven't heard anything since.
Component: General → Other
Product: Firefox → External Software Affecting Firefox
Version: 40 Branch → unspecified
It sounds like Ryan owns this for now.
Assignee: nobody → ryanvm
We contacted Trend Micro on the 20th of April and haven't heard anything from them since. I've sent them another note asking for updates. If we don't hear back by next week, I'm inclined to start seeing what our blacklisting options are here.
This is the #19 crash on release with 1939 crashes in the last week.
from past experience on sumo it appears that disabling the "Trend Micro BEP Firefox Extension" addon (tmbepff@trendmicro.com) is enough to stop the crashes, so this might be a possible avenue to blocklist and reduce the crashiness induced by trend micro...
Tracking. And yes let's try blocklisting. 1% of crashes on release is a lot and I'd love to stop that from happening.
Jorge (or Ryan) can you prepare to blocklist this? We're still seeing about 1000 crashes a day on release.
tracking-firefox46: + → blocking
Flags: needinfo?(ryanvm)
Flags: needinfo?(jorge)
Agreed, TM is aware that we were considering it and I haven't heard back since.
Flags: needinfo?(ryanvm)
I sent a message to the developers via AMO. Since this isn't the first time we approach them about this, I think it's okay to move forward with the block. -> Andrew for filing the blocklist bug for the existing versions. AMO ID: 638848 GUID: tmbepff@trendmicro.com
Flags: needinfo?(jorge) → needinfo?(awilliamson)
> -> Andrew for filing the blocklist bug for the existing versions. Filing and executing, that is.
Depends on: 1275245
Filed and executed in bug 1275245
Flags: needinfo?(awilliamson)
do we know how long this crash has been happening for? We're trying to narrow down which versions need to be blocked (as they have a 9.0.0 branch they want to release a bugfix update to)
in a spot check of correlation data it looks like these crashes happened with various versions of their 8.0, 9.0 and 9.1 branch. so if they are still supporting their 9.0 branch and would provide an update to it that fixes it, we'd probably need to inquire from trend micro what's their last affected version there (or this may be available from AMO data).
Looks like we had a dropoff at the end of May from the blocklist: https://crash-stats.mozilla.com/signature/?date=%3E2016-05-01&signature=memcpy+|+tmbpffcore.dll%400x4307#graphs Still around 50 crashes a day but that's great as it's down from 300 per day. Wontfix for 46 at this point as 47 is about to be released. There are still crashes with these signatures in 47 RC. We may still want to block more versions if the remaining crashes are still from Trend micro.
status-firefox46: affected → wontfix
i'm also marking this as fixed by bug 1275245. there are only a handful of these signatures around each day still (users would be able to manually reactivate the blocklisted addon...)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
48 is affected with a small volume, 49 is not, clausing
status-firefox47: affected → wontfix
status-firefox48: affected → wontfix
status-firefox49: --- → fixed
You need to log in before you can comment on or make changes to this bug.