This bug was filed from the Socorro interface and is report bp-e469ff56-a56f-4c8a-848c-365f82140905. ============================================================= Win7 only crash in ole.dll reason vary: EXCEPTION_ACCESS_VIOLATION_READ EXCEPTION_PRIV_INSTRUCTION EXCEPTION_ACCESS_VIOLATION_WRITE Frame Module Signature Source 0 ole32.dll GetCurrentContext() 1 ole32.dll CClientContextActivator::CreateInstance(IUnknown*, IActivationPropertiesIn*, IActivationPropertiesOut**) 2 ole32.dll CComActivator::DoCreateInstance(_GUID const&, IUnknown*, unsigned long, _COSERVERINFO*, unsigned long, tagMULTI_QI*, ActivationPropertiesIn*) 3 ole32.dll CoCreateInstanceEx 4 ole32.dll CoCreateInstance 5 xul.dll mozilla::layers::Nv3DVUtils::Initialize() gfx/layers/d3d9/Nv3DVUtils.cpp 6 xul.dll mozilla::layers::DeviceManagerD3D9::Init() gfx/layers/d3d9/DeviceManagerD3D9.cpp 7 xul.dll gfxWindowsPlatform::GetD3D9DeviceManager() gfx/thebes/gfxWindowsPlatform.cpp 8 xul.dll mozilla::layers::CompositorD3D9::Initialize() gfx/layers/d3d9/CompositorD3D9.cpp 9 xul.dll mozilla::layers::CompositorParent::InitializeLayerManager(nsTArray<mozilla::layers::LayersBackend> const&) gfx/layers/ipc/CompositorParent.cpp 10 xul.dll mozilla::layers::CompositorParent::AllocPLayerTransactionParent(nsTArray<mozilla::layers::LayersBackend> const&, unsigned __int64 const&, mozilla::layers::TextureFactoryIdentifier*, bool*) gfx/layers/ipc/CompositorParent.cpp 11 xul.dll mozilla::layers::PCompositorParent::OnMessageReceived(IPC::Message const&, IPC::Message*&) obj-firefox/ipc/ipdl/PCompositorParent.cpp 12 xul.dll mozilla::ipc::MessageChannel::DispatchSyncMessage(IPC::Message const&) ipc/glue/MessageChannel.cpp 13 xul.dll mozilla::ipc::MessageChannel::DispatchMessageW(IPC::Message const&) ipc/glue/MessageChannel.cpp 14 xul.dll mozilla::ipc::MessageChannel::OnMaybeDequeueOne() ipc/glue/MessageChannel.cpp 15 xul.dll MessageLoop::RunTask(Task*) ipc/chromium/src/base/message_loop.cc 16 xul.dll MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) ipc/chromium/src/base/message_loop.cc 17 xul.dll MessageLoop::DoWork() ipc/chromium/src/base/message_loop.cc 18 xul.dll base::MessagePumpDefault::Run(base::MessagePump::Delegate*) ipc/chromium/src/base/message_pump_default.cc 19 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 20 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 21 xul.dll base::Thread::ThreadMain() ipc/chromium/src/base/thread.cc 22 xul.dll `anonymous namespace'::ThreadFunc(void*) tools/profiler/platform-win32.cc 23 kernel32.dll BaseThreadInitThunk 24 ntdll.dll __RtlUserThreadStart 25 ntdll.dll _RtlUserThreadStart
[Tracking Requested - why for this release]: This is a topcrasher on 33beta at #11 on volume list.
status-firefox33: --- → affected
status-firefox34: --- → affected
status-firefox35: --- → affected
tracking-firefox33: --- → ?
tracking-firefox33: ? → +
tracking-firefox34: --- → +
tracking-firefox35: --- → +
Nicolas, Bas, could you help us here? Thanks
Created attachment 8493979 [details] [diff] [review] Put stereo video behind a pref (off by default) The reason crash here is unclear since it's in close-source 3rd party code. I haven't found the documentation for Nv3DV, it could be that it cannot be initialized out of the main thread (or something else related to threads since this crash seems to be related to OMTC). stereo video is only available for D3D9 users (not lucky enough to get D3D11 but lucky enough to not fallback to software compositing). Among those users, close to nobody actually use the feature, so let's just disable it. We may even remove the code entirely soon.
Assignee: nobody → nical.bugzilla
Attachment #8493979 - Flags: review?(bas)
Attachment #8493979 - Flags: review?(bas) → review+
Juan, I think you did some testing of our releases for stereo video, so you should know about this. Read comment #3. I wonder if we also should reach out to Nvidia about this, as IIRC they have been testing this feature as well.
Nicolas, could you request the uplifts for aurora & beta? Thanks
Crash Signature: [@ GetCurrentContext()] → [@ GetCurrentContext()] [@ CPrivAlloc::operator delete(void*) ]
I don't know that it makes much difference but wanted to mention there are some known crashes and issues in versions of ole32.dll that shipped in Win7 SP1 that got corrected by hotfixes such as KB2541119 (or KB2545479, KB2707589 and KB2457836). Curious to know what version of ole32.dll the user was running. Any way we could pull info like build number out of DLLs and include in crash stats?
Comment on attachment 8493979 [details] [diff] [review] Put stereo video behind a pref (off by default) Approval Request Comment [Feature/regressing bug #]: [User impact if declined]: Frequent crashes on windows for D3D9 users [Describe test coverage new/current, TBPL]: [Risks and why]: low risk, trivial patch, disables a crashy code path. [String/UUID change made/needed]:
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-firefox35: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
(In reply to Arthur K. from comment #8) > I don't know that it makes much difference but wanted to mention there are > some known crashes and issues in versions of ole32.dll that shipped in Win7 > SP1 that got corrected by hotfixes such as KB2541119 (or KB2545479, > KB2707589 and KB2457836). Curious to know what version of ole32.dll the user > was running. Any way we could pull info like build number out of DLLs and > include in crash stats? We do collect module version information, but sometimes it's hard to get at. In this case this is pretty much entirely Win7SP0, based on the platform version facet here (the text splitting needs improvement): https://crash-stats.mozilla.com/search/?signature=~GetCurrentContext&_facets=platform_version 1 6.1.7600 3469 99.34 % More generally you can see version correlations in files like this: https://crash-analysis.mozilla.com/crash_analysis/20140923/ -- but I guess ole32.dll isn't considered 'interesting' by our scripts.
Well, if in this particular case the user is at SP0 level, then it may likely be a false positive or behavior that's correctable via SP1. Oh well.
(In reply to Arthur K. from comment #12) > Well, if in this particular case the user is at SP0 level, then it may > likely be a false positive or behavior that's correctable via SP1. Oh well. SP1 is blocked from installing on machines with certain Intel drivers. (KB2498452)
status-firefox33: affected → fixed
status-firefox34: affected → fixed
Looking through Socorro for crashes in the past 3 days, I see the following: 1. GetCurrentContext() - NO crashes in Firefox 33 Beta 8 2. CPrivAlloc::operator delete(void*) - 26 crashes in Firefox 33 Beta 8 A few more days are needed to properly evaluate the impact of the fix, but I'm not sure whether we should expect no crashes for both signatures or not.
For Nightly and Aurora it's a similar story, with NO crashes for the first signature, and 5 crashes for the second one in builds after the fix landed.
CPrivAlloc::operator delete is a signature that can occur from different causes. This case here would be crashes under mozilla::layers::Nv3DVUtils::Initialize, while at least one other known case is tracked by bug 854176. You should look at the crash stack for the reports to determine which one you're seeing.
Thank you Benjamin... I really should have seen that! Going through individual signatures I can see that all are in fact in WININET, so covered by bug 854176. Since there are no new crashes related to this issue, I'm marking it as Verified.
Status: RESOLVED → VERIFIED
status-firefox33: fixed → verified
status-firefox34: fixed → verified
status-firefox35: fixed → verified
Summary: crash in GetCurrentContext() → crash in GetCurrentContext() - Put stereo video behind a pref
You need to log in before you can comment on or make changes to this bug.