Various gfx crashes/assertions when using ffvp8 or ffvp9 decoder

RESOLVED WONTFIX

Status

()

defect
P3
normal
RESOLVED WONTFIX
4 years ago
4 months ago

People

(Reporter: jya, Unassigned)

Tracking

(Blocks 1 bug, {crash})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox46 affected)

Details

(Whiteboard: gfx-noted)

Attachments

(2 attachments, 1 obsolete attachment)

Reporter

Description

4 years ago
While investigating bug 1214462, I've encountered various crashes or assertions in the gfx code.

All happening on Windows XP or Vista (none seen in Windows 8 or Window 10), almost all located in the D3D9 compositor.

Assertion #1:
https://treeherder.mozilla.org/logviewer.html#?job_id=14994593&repo=try
 02:50:21     INFO -  Assertion failure: (mType) == (aType) (unexpected type tag), at c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\src\obj-firefox\ipc\ipdl\_ipdlheaders\mozilla/layers/LayersSurfaces.h:2233
 02:50:21     INFO -  #01: mozilla::layers::ISurfaceAllocator::DestroySharedSurface(mozilla::layers::SurfaceDescriptor *) [gfx/layers/ipc/ISurfaceAllocator.cpp:178]
 02:50:21     INFO -  #02: mozilla::layers::ClientLayerManager::MakeSnapshotIfRequired() [gfx/layers/client/ClientLayerManager.cpp:538]
 02:50:21     INFO -  #03: mozilla::layers::ClientLayerManager::EndTransaction(void (*)(mozilla::layers::PaintedLayer *,gfxContext *,mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const &,mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const &,mozilla::layers::DrawRegionClip,mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const &,void *),void *,mozilla::layers::LayerManager::EndTransactionFlags) [gfx/layers/client/ClientLayerManager.cpp:335]
 02:50:21     INFO -  #04: nsDisplayList::PaintRoot(nsDisplayListBuilder *,nsRenderingContext *,unsigned int) [layout/base/nsDisplayList.cpp:1759]
 02:50:21     INFO -  #05: nsLayoutUtils::PaintFrame(nsRenderingContext *,nsIFrame *,nsRegion const &,unsigned int,unsigned int) [layout/base/nsLayoutUtils.cpp:3363]
 02:50:21     INFO -  #06: PresShell::RenderDocument(nsRect const &,unsigned int,unsigned int,gfxContext *) [layout/base/nsPresShell.cpp:4613]
 02:50:21     INFO -  #07: mozilla::dom::CanvasRenderingContext2D::DrawWindow(nsGlobalWindow &,double,double,double,double,nsAString_internal const &,unsigned int,mozilla::ErrorResult &) [dom/canvas/CanvasRenderingContext2D.cpp:4913]
 02:50:21     INFO -  #08: mozilla::dom::CanvasRenderingContext2DBinding::drawWindow [obj-firefox/dom/bindings/CanvasRenderingContext2DBinding.cpp:5223]
 02:50:21     INFO -  #09: mozilla::dom::GenericBindingMethod(JSContext *,unsigned int,JS::Value *) [dom/bindings/BindingUtils.cpp:2718]
 02:50:21     INFO -  #10: js::CallJSNative(JSContext *,bool (*)(JSContext *,unsigned int,JS::Value *),JS::CallArgs const &) [js/src/jscntxtinlines.h:235]
 02:50:21     INFO -  #11: js::Invoke(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [js/src/vm/Interpreter.cpp:460]
 02:50:21     INFO -  #12: js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value const *,JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:512]
 02:50:21     INFO -  #13: js::DirectProxyHandler::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) [js/src/proxy/DirectProxyHandler.cpp:77]
 02:50:21     INFO -  #14: js::CrossCompartmentWrapper::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) [js/src/proxy/CrossCompartmentWrapper.cpp:289]
 02:50:21     INFO -  #15: xpc::AddonWrapper<js::CrossCompartmentWrapper>::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) [js/xpconnect/wrappers/AddonWrapper.cpp:139]
 02:50:21     INFO -  #16: js::Proxy::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) [js/src/proxy/Proxy.cpp:391]
 02:50:21     INFO -  #17: js::proxy_Call(JSContext *,unsigned int,JS::Value *) [js/src/proxy/Proxy.cpp:683]
 02:50:21     INFO -  #18: js::CallJSNative(JSContext *,bool (*)(JSContext *,unsigned int,JS::Value *),JS::CallArgs const &) [js/src/jscntxtinlines.h:235]
 02:50:21     INFO -  #19: js::Invoke(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [js/src/vm/Interpreter.cpp:448]
 02:50:21     INFO -  #20: js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value const *,JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:512]
 02:50:21     INFO -  #21: js::jit::DoCallFallback [js/src/jit/BaselineIC.cpp:6184]
 02:50:21     INFO -  #22: ??? (???:???)
 02:50:21     INFO -  #23: ??? (???:???)
 02:50:21     INFO -  #24: ??? (???:???)
 02:50:21     INFO -  #25: EnterBaseline [js/src/jit/BaselineJIT.cpp:137]
 02:50:21     INFO -  #26: js::jit::EnterBaselineMethod(JSContext *,js::RunState &) [js/src/jit/BaselineJIT.cpp:173]
 02:50:21     INFO -  #27: js::RunScript(JSContext *,js::RunState &) [js/src/vm/Interpreter.cpp:397]
 02:50:21     INFO -  #28: js::Invoke(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [js/src/vm/Interpreter.cpp:478]
 02:50:21     INFO -  #29: js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value const *,JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:512]
 02:50:21     INFO -  #30: JS::Call(JSContext *,JS::Handle<JS::Value>,JS::Handle<JS::Value>,JS::HandleValueArray const &,JS::MutableHandle<JS::Value>) [js/src/jsapi.cpp:2858]
 02:50:21     INFO -  #31: xpc::SandboxCallableProxyHandler::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) [js/xpconnect/src/Sandbox.cpp:693]
 02:50:21     INFO -  #32: js::Proxy::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) [js/src/proxy/Proxy.cpp:391]
 02:50:21     INFO -  #33: js::proxy_Call(JSContext *,unsigned int,JS::Value *) [js/src/proxy/Proxy.cpp:683]
 02:50:21     INFO -  #34: js::CallJSNative(JSContext *,bool (*)(JSContext *,unsigned int,JS::Value *),JS::CallArgs const &) [js/src/jscntxtinlines.h:235]
 02:50:21     INFO -  #35: js::Invoke(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [js/src/vm/Interpreter.cpp:448]
 02:50:21     INFO -  #36: js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value const *,JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:512]
 02:50:21     INFO -  #37: js::jit::DoCallFallback [js/src/jit/BaselineIC.cpp:6184]
 02:50:21     INFO -  #38: ??? (???:???)
 02:50:21     INFO -  #39: ??? (???:???)
 02:50:21     INFO -  #40: ??? (???:???)
 02:50:21     INFO -  #41: EnterBaseline [js/src/jit/BaselineJIT.cpp:137]
 02:50:21     INFO -  #42: js::jit::EnterBaselineMethod(JSContext *,js::RunState &) [js/src/jit/BaselineJIT.cpp:173]
 02:50:21     INFO -  #43: js::RunScript(JSContext *,js::RunState &) [js/src/vm/Interpreter.cpp:397]
 02:50:21     INFO -  #44: js::Invoke(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [js/src/vm/Interpreter.cpp:478]
 02:50:21     INFO -  #45: js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value const *,JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:512]
 02:50:21     INFO -  #46: JS::Call(JSContext *,JS::Handle<JS::Value>,JS::Handle<JS::Value>,JS::HandleValueArray const &,JS::MutableHandle<JS::Value>) [js/src/jsapi.cpp:2858]
 02:50:21     INFO -  #47: xpc::SandboxCallableProxyHandler::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) [js/xpconnect/src/Sandbox.cpp:693]
 02:50:21     INFO -  #48: js::Proxy::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) [js/src/proxy/Proxy.cpp:391]
 02:50:21     INFO -  #49: js::proxy_Call(JSContext *,unsigned int,JS::Value *) [js/src/proxy/Proxy.cpp:683]
 02:50:21     INFO -  #50: js::CallJSNative(JSContext *,bool (*)(JSContext *,unsigned int,JS::Value *),JS::CallArgs const &) [js/src/jscntxtinlines.h:235]
 02:50:21     INFO -  #51: js::Invoke(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [js/src/vm/Interpreter.cpp:448]
 02:50:21     INFO -  #52: js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value const *,JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:512]
 02:50:21     INFO -  #53: js::jit::DoCallFallback [js/src/jit/BaselineIC.cpp:6184]
 02:50:21     INFO -  #54: ??? (???:???)
 02:50:21     INFO -  #55: ??? (???:???)
 02:50:21     INFO -  #56: ??? (???:???)
 02:50:21     INFO -  #57: EnterBaseline [js/src/jit/BaselineJIT.cpp:137]
 02:50:21     INFO -  #58: js::jit::EnterBaselineMethod(JSContext *,js::RunState &) [js/src/jit/BaselineJIT.cpp:173]
 02:50:21     INFO -  #59: js::RunScript(JSContext *,js::RunState &) [js/src/vm/Interpreter.cpp:397]
 02:50:21     INFO -  #60: js::Invoke(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [js/src/vm/Interpreter.cpp:478]
 02:50:21     INFO -  #61: js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value const *,JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:512]
 02:50:21     INFO -  #62: JS::Call(JSContext *,JS::Handle<JS::Value>,JS::Handle<JS::Value>,JS::HandleValueArray const &,JS::MutableHandle<JS::Value>) [js/src/jsapi.cpp:2858]
 02:50:21     INFO -  #63: xpc::SandboxCallableProxyHandler::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) [js/xpconnect/src/Sandbox.cpp:693]
 02:50:21     INFO -  #64: js::Proxy::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) [js/src/proxy/Proxy.cpp:391]
 02:50:21     INFO -  #65: js::proxy_Call(JSContext *,unsigned int,JS::Value *) [js/src/proxy/Proxy.cpp:683]
 02:50:21     INFO -  #66: js::CallJSNative(JSContext *,bool (*)(JSContext *,unsigned int,JS::Value *),JS::CallArgs const &) [js/src/jscntxtinlines.h:235]
 02:50:21     INFO -  #67: js::Invoke(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [js/src/vm/Interpreter.cpp:448]
 02:50:21     INFO -  #68: js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value const *,JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:512]
 02:50:21     INFO -  #69: js::jit::DoCallFallback [js/src/jit/BaselineIC.cpp:6184]
 02:50:21     INFO -  #70: ??? (???:???)
 02:50:21     INFO -  #71: ??? (???:???)
 02:50:21     INFO -  #72: ??? (???:???)
 02:50:21     INFO -  #73: EnterBaseline [js/src/jit/BaselineJIT.cpp:137]
 02:50:21     INFO -  #74: js::jit::EnterBaselineMethod(JSContext *,js::RunState &) [js/src/jit/BaselineJIT.cpp:173]
 02:50:21     INFO -  #75: js::RunScript(JSContext *,js::RunState &) [js/src/vm/Interpreter.cpp:397]
 02:50:21     INFO -  #76: js::Invoke(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [js/src/vm/Interpreter.cpp:478]
 02:50:21     INFO -  #77: js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value const *,JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:512]
 02:50:21     INFO -  #78: JS_CallFunctionValue(JSContext *,JS::Handle<JSObject *>,JS::Handle<JS::Value>,JS::HandleValueArray const &,JS::MutableHandle<JS::Value>) [js/src/jsapi.cpp:2811]
 02:50:21     INFO -  #79: nsFrameMessageManager::ReceiveMessage(nsISupports *,nsIFrameLoader *,bool,nsAString_internal const &,bool,mozilla::dom::ipc::StructuredCloneData *,mozilla::jsipc::CpowHolder *,nsIPrincipal *,nsTArray<mozilla::dom::ipc::StructuredCloneData> *) [dom/base/nsFrameMessageManager.cpp:1229]
 02:50:21     INFO -  #80: nsFrameMessageManager::ReceiveMessage(nsISupports *,nsIFrameLoader *,nsAString_internal const &,bool,mozilla::dom::ipc::StructuredCloneData *,mozilla::jsipc::CpowHolder *,nsIPrincipal *,nsTArray<mozilla::dom::ipc::StructuredCloneData> *) [dom/base/nsFrameMessageManager.cpp:1043]
 02:50:21     INFO -  #81: nsInProcessTabChildGlobal::DoSendBlockingMessage(JSContext *,nsAString_internal const &,mozilla::dom::ipc::StructuredCloneData &,JS::Handle<JSObject *>,nsIPrincipal *,nsTArray<mozilla::dom::ipc::StructuredCloneData> *,bool) [dom/base/nsInProcessTabChildGlobal.cpp:44]
 02:50:21     INFO -  #82: nsFrameMessageManager::SendMessage(nsAString_internal const &,JS::Handle<JS::Value>,JS::Handle<JS::Value>,nsIPrincipal *,JSContext *,unsigned char,JS::MutableHandle<JS::Value>,bool) [dom/base/nsFrameMessageManager.cpp:733]
 02:50:21     INFO -  #83: nsFrameMessageManager::SendSyncMessage(nsAString_internal const &,JS::Handle<JS::Value>,JS::Handle<JS::Value>,nsIPrincipal *,JSContext *,unsigned char,JS::MutableHandle<JS::Value>) [dom/base/nsFrameMessageManager.cpp:681]
 02:50:21     INFO -  #84: nsInProcessTabChildGlobal::SendSyncMessage(nsAString_internal const &,JS::Handle<JS::Value>,JS::Handle<JS::Value>,nsIPrincipal *,JSContext *,unsigned char,JS::MutableHandle<JS::Value>) [dom/base/nsInProcessTabChildGlobal.h:61]
 02:50:21     INFO -  #85: NS_InvokeByIndex [xpcom/reflect/xptcall/md/win32/xptcinvoke.cpp:71]
 02:50:21     INFO -  #86: CallMethodHelper::Invoke() [js/xpconnect/src/XPCWrappedNative.cpp:2097]
 02:50:21     INFO -  #87: XPCWrappedNative::CallMethod(XPCCallContext &,XPCWrappedNative::CallMode) [js/xpconnect/src/XPCWrappedNative.cpp:1381]
 02:50:21     INFO -  #88: XPC_WN_CallMethod(JSContext *,unsigned int,JS::Value *) [js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1115]
 02:50:21     INFO -  #89: ??? (???:???)
 02:50:21     INFO -  #90: ??? (???:???)
 02:50:21     INFO -  #91: ??? (???:???)
 02:50:21     INFO -  #92: ??? (???:???)
 02:50:21     INFO -  #93: ??? (???:???)
 02:50:21     INFO -  #94: EnterBaseline [js/src/jit/BaselineJIT.cpp:137]
 02:50:21     INFO -  #95: js::jit::EnterBaselineMethod(JSContext *,js::RunState &) [js/src/jit/BaselineJIT.cpp:173]
 02:50:21     INFO -  #96: js::RunScript(JSContext *,js::RunState &) [js/src/vm/Interpreter.cpp:397]
 02:50:21     INFO -  #97: js::Invoke(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [js/src/vm/Interpreter.cpp:478]
 02:50:21     INFO -  #98: js::fun_apply(JSContext *,unsigned int,JS::Value *) [js/src/jsfun.cpp:1264]
 02:50:21     INFO -  #99: js::CallJSNative(JSContext *,bool (*)(JSContext *,unsigned int,JS::Value *),JS::CallArgs const &) [js/src/jscntxtinlines.h:235]
 02:50:21     INFO -  #100: js::Invoke(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [js/src/vm/Interpreter.cpp:460]
 02:50:21     INFO -  #101: js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value const *,JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:512]
 02:50:21     INFO -  #102: js::DirectProxyHandler::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) [js/src/proxy/DirectProxyHandler.cpp:77]
 02:50:21     INFO -  #103: js::CrossCompartmentWrapper::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) [js/src/proxy/CrossCompartmentWrapper.cpp:289]
 02:50:21     INFO -  #104: js::Proxy::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) [js/src/proxy/Proxy.cpp:391]
 02:50:21     INFO -  #105: js::proxy_Call(JSContext *,unsigned int,JS::Value *) [js/src/proxy/Proxy.cpp:683]
 02:50:21     INFO -  #106: js::CallJSNative(JSContext *,bool (*)(JSContext *,unsigned int,JS::Value *),JS::CallArgs const &) [js/src/jscntxtinlines.h:235]
 02:50:21     INFO -  #107: js::Invoke(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [js/src/vm/Interpreter.cpp:448]
 02:50:21     INFO -  #108: js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value const *,JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:512]
 02:50:21     INFO -  #109: js::jit::DoCallFallback [js/src/jit/BaselineIC.cpp:6184]
 02:50:21     INFO -  #110: ??? (???:???)
 02:50:21     INFO -  #111: ??? (???:???)
 02:50:21     INFO -  #112: ??? (???:???)
 02:50:21     INFO -  #113: EnterBaseline [js/src/jit/BaselineJIT.cpp:137]
 02:50:21     INFO -  #114: js::jit::EnterBaselineMethod(JSContext *,js::RunState &) [js/src/jit/BaselineJIT.cpp:173]
 02:50:21     INFO -  #115: js::RunScript(JSContext *,js::RunState &) [js/src/vm/Interpreter.cpp:397]
 02:50:21     INFO -  #116: js::Invoke(JSContext *,JS::CallArgs const &,js::MaybeConstruct) [js/src/vm/Interpreter.cpp:478]
 02:50:21     INFO -  #117: js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value const *,JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:512]
 02:50:21     INFO -  #118: JS_CallFunctionValue(JSContext *,JS::Handle<JSObject *>,JS::Handle<JS::Value>,JS::HandleValueArray const &,JS::MutableHandle<JS::Value>) [js/src/jsapi.cpp:2811]
 02:50:21     INFO -  #119: nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS *,unsigned short,XPTMethodDescriptor const *,nsXPTCMiniVariant *) [js/xpconnect/src/XPCWrappedJSClass.cpp:1222]
 02:50:21     INFO -  #120: nsXPCWrappedJS::CallMethod(unsigned short,XPTMethodDescriptor const *,nsXPTCMiniVariant *) [js/xpconnect/src/XPCWrappedJS.cpp:603]
 02:50:21     INFO -  #121: PrepareAndDispatch [xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:85]
 02:50:21     INFO -  #122: SharedStub [xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:113]
 02:50:21     INFO -  #123: nsTimerImpl::Fire() [xpcom/threads/nsTimerImpl.cpp:529]
 02:50:21     INFO -  #124: nsTimerEvent::Run() [xpcom/threads/TimerThread.cpp:286]
 02:50:21     INFO -  #125: nsThread::ProcessNextEvent(bool,bool *) [xpcom/threads/nsThread.cpp:989]
 02:50:21     INFO -  #126: NS_ProcessNextEvent(nsIThread *,bool) [xpcom/glue/nsThreadUtils.cpp:297]
 02:50:21     INFO -  #127: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate *) [ipc/glue/MessagePump.cpp:95]
 02:50:21     INFO -  #128: MessageLoop::RunInternal() [ipc/chromium/src/base/message_loop.cc:234]
 02:50:21     INFO -  #129: MessageLoop::RunHandler() [ipc/chromium/src/base/message_loop.cc:228]
 02:50:21     INFO -  #130: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:202]
 02:50:21     INFO -  #131: nsBaseAppShell::Run() [widget/nsBaseAppShell.cpp:158]
 02:50:21     INFO -  #132: nsAppShell::Run() [widget/windows/nsAppShell.cpp:259]
 02:50:21     INFO -  #133: nsAppStartup::Run() [toolkit/components/startup/nsAppStartup.cpp:282]
 02:50:21     INFO -  #134: XREMain::XRE_mainRun() [toolkit/xre/nsAppRunner.cpp:4288]
 02:50:21     INFO -  #135: XREMain::XRE_main(int,char * * const,nsXREAppData const *) [toolkit/xre/nsAppRunner.cpp:4385]
 02:50:21     INFO -  #136: XRE_main [toolkit/xre/nsAppRunner.cpp:4487]
 02:50:21     INFO -  #137: do_main [browser/app/nsBrowserApp.cpp:212]
 02:50:21     INFO -  #138: NS_internal_main(int,char * *) [browser/app/nsBrowserApp.cpp:352]
 02:50:21     INFO -  #139: wmain [toolkit/xre/nsWindowsWMain.cpp:138]
 02:50:21     INFO -  #140: __tmainCRTStartup [f:/dd/vctools/crt/crtw32/startup/crt0.c:255]
 02:50:21     INFO -  #141: kernel32 + 0x17067
 02:50:22  WARNING -  TEST-UNEXPECTED-FAIL | file:///C:/slave/test/build/tests/reftest/tests/layout/reftests/webm-video/object-fit-fill-webm-002.html | application terminated with exit code 1
 02:50:26     INFO -  mozcrash INFO | Saved minidump as C:\slave\test\build\blobber_upload_dir\5e568026-c84c-46d7-91fe-74a9ec988c74.dmp

Assertion #2
https://treeherder.mozilla.org/logviewer.html#?job_id=14994604&repo=try
 02:50:04     INFO -  Assertion failure: mRawPtr != 0 (You can't dereference a NULL RefPtr with operator->().), at c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\src\obj-firefox\dist\include\mozilla/RefPtr.h:276
 02:50:04     INFO -  #01: mozilla::layers::CompositorD3D9::EndFrame() [gfx/layers/d3d9/CompositorD3D9.cpp:671]
 02:50:04     INFO -  #02: mozilla::layers::LayerManagerComposite::Render(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const &) [gfx/layers/composite/LayerManagerComposite.cpp:904]
 02:50:04     INFO -  #03: mozilla::layers::LayerManagerComposite::UpdateAndRender() [gfx/layers/composite/LayerManagerComposite.cpp:453]
 02:50:04     INFO -  #04: mozilla::layers::LayerManagerComposite::EndTransaction(mozilla::TimeStamp const &,mozilla::layers::LayerManager::EndTransactionFlags) [gfx/layers/composite/LayerManagerComposite.cpp:368]
 02:50:04     INFO -  #05: mozilla::layers::CompositorParent::CompositeToTarget(mozilla::gfx::DrawTarget *,mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const *) [gfx/layers/ipc/CompositorParent.cpp:1171]
 02:50:04     INFO -  #06: mozilla::layers::CompositorVsyncScheduler::ForceComposeToTarget(mozilla::gfx::DrawTarget *,mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const *) [gfx/layers/ipc/CompositorParent.cpp:474]
 02:50:04     INFO -  #07: mozilla::layers::CompositorParent::ForceComposeToTarget(mozilla::gfx::DrawTarget *,mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const *) [gfx/layers/ipc/CompositorParent.cpp:1234]
 02:50:04     INFO -  #08: mozilla::layers::CompositorParent::RecvMakeSnapshot(mozilla::layers::SurfaceDescriptor const &,mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const &) [gfx/layers/ipc/CompositorParent.cpp:746]
 02:50:04     INFO -  #09: mozilla::layers::PCompositorParent::OnMessageReceived(IPC::Message const &,IPC::Message * &) [obj-firefox/ipc/ipdl/PCompositorParent.cpp:914]
 02:50:04     INFO -  #10: mozilla::ipc::MessageChannel::DispatchSyncMessage(IPC::Message const &,IPC::Message * &) [ipc/glue/MessageChannel.cpp:1356]
 02:50:04     INFO -  #11: mozilla::ipc::MessageChannel::DispatchMessageW(IPC::Message const &) [ipc/glue/MessageChannel.cpp:1301]
 02:50:04     INFO -  #12: mozilla::ipc::MessageChannel::OnMaybeDequeueOne() [ipc/glue/MessageChannel.cpp:1277]
 02:50:04     INFO -  #13: MessageLoop::RunTask(Task *) [ipc/chromium/src/base/message_loop.cc:365]
 02:50:04     INFO -  #14: MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const &) [ipc/chromium/src/base/message_loop.cc:375]
 02:50:04     INFO -  #15: MessageLoop::DoWork() [ipc/chromium/src/base/message_loop.cc:459]
 02:50:04     INFO -  #16: base::MessagePumpForUI::DoRunLoop() [ipc/chromium/src/base/message_pump_win.cc:211]
 02:50:04     INFO -  #17: base::MessagePumpWin::Run(base::MessagePump::Delegate *) [ipc/chromium/src/base/message_pump_win.h:78]
 02:50:04     INFO -  #18: MessageLoop::RunInternal() [ipc/chromium/src/base/message_loop.cc:234]
 02:50:04     INFO -  #19: MessageLoop::RunHandler() [ipc/chromium/src/base/message_loop.cc:228]
 02:50:04     INFO -  #20: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:202]
 02:50:04     INFO -  #21: base::Thread::ThreadMain() [ipc/chromium/src/base/thread.cc:175]
 02:50:04     INFO -  #22: `anonymous namespace'::ThreadFunc(void *) [ipc/chromium/src/base/platform_thread_win.cc:27]
 02:50:04     INFO -  #23: kernel32 + 0xb713
 02:50:05  WARNING -  TEST-UNEXPECTED-FAIL | file:///C:/slave/test/build/tests/reftest/tests/layout/reftests/webm-video/object-position-webm-002.html | application terminated with exit code 1
 02:50:09     INFO -  mozcrash INFO | Saved minidump as C:\slave\test\build\blobber_upload_dir\c9f3ef24-89e9-45e0-8e0e-4b8b777a0486.dmp


Assertion #3
https://treeherder.mozilla.org/logviewer.html#?job_id=14994611&repo=try
 02:50:24     INFO -  [3440] WARNING: Could not create a d3d9 texture: file c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/src/gfx/layers/d3d9/TextureD3D9.cpp, line 471
 02:50:24     INFO -  ??????????p: T[GFX2-]: ASurface Init failed with Cairo status 1 on 0x06EE5FD8
 02:50:24     INFO -  [3440] WARNING: Could not create DIB surface: file c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/src/gfx/layers/TextureDIB.cpp, line 171
 02:50:24     INFO -  [GFX3-]: BufferTextureData: Failed to allocate 3200000 bytes
 02:50:24     INFO -  [GFX1]: Failed 2 buffer db=0x00000000 dw=0x00000000 for 0, 0, 800, 1000
 02:50:24     INFO -  Assertion failure: false (An assert from the graphics logger), at c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\src\gfx\2d\Logging.h:523
 02:50:24     INFO -  #01: mozilla::gfx::Log<1,mozilla::gfx::CriticalLogger>::Flush() [gfx/2d/Logging.h:297]
 02:50:24     INFO -  #02: mozilla::layers::RotatedContentBuffer::BeginPaint(mozilla::layers::PaintedLayer *,unsigned int) [gfx/layers/RotatedBuffer.cpp:674]
 02:50:24     INFO -  #03: mozilla::layers::ContentClientRemoteBuffer::BeginPaintBuffer(mozilla::layers::PaintedLayer *,unsigned int) [gfx/layers/client/ContentClient.h:218]
 02:50:24     INFO -  #04: mozilla::layers::ClientPaintedLayer::PaintThebes() [gfx/layers/client/ClientPaintedLayer.cpp:66]
 02:50:24     INFO -  #05: mozilla::layers::ClientPaintedLayer::RenderLayerWithReadback(mozilla::layers::ReadbackProcessor *) [gfx/layers/client/ClientPaintedLayer.cpp:149]
 02:50:24     INFO -  #06: mozilla::layers::ClientContainerLayer::RenderLayer() [gfx/layers/client/ClientContainerLayer.h:68]
 02:50:24     INFO -  #07: mozilla::layers::ClientLayer::RenderLayerWithReadback(mozilla::layers::ReadbackProcessor *) [gfx/layers/client/ClientLayerManager.h:391]
 02:50:24     INFO -  #08: mozilla::layers::ClientLayerManager::EndTransactionInternal(void (*)(mozilla::layers::PaintedLayer *,gfxContext *,mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const &,mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const &,mozilla::layers::DrawRegionClip,mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const &,void *),void *,mozilla::layers::LayerManager::EndTransactionFlags) [gfx/layers/client/ClientLayerManager.cpp:283]
 02:50:24     INFO -  #09: mozilla::layers::ClientLayerManager::EndTransaction(void (*)(mozilla::layers::PaintedLayer *,gfxContext *,mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const &,mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const &,mozilla::layers::DrawRegionClip,mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const &,void *),void *,mozilla::layers::LayerManager::EndTransactionFlags) [gfx/layers/client/ClientLayerManager.cpp:326]
 02:50:24     INFO -  #10: nsDisplayList::PaintRoot(nsDisplayListBuilder *,nsRenderingContext *,unsigned int) [layout/base/nsDisplayList.cpp:1759]
 02:50:24     INFO -  #11: nsLayoutUtils::PaintFrame(nsRenderingContext *,nsIFrame *,nsRegion const &,unsigned int,unsigned int) [layout/base/nsLayoutUtils.cpp:3363]
 02:50:24     INFO -  #12: PresShell::Paint(nsView *,nsRegion const &,unsigned int) [layout/base/nsPresShell.cpp:6015]
 02:50:24     INFO -  #13: nsViewManager::ProcessPendingUpdatesPaint(nsIWidget *) [view/nsViewManager.cpp:467]
 02:50:24     INFO -  #14: nsViewManager::ProcessPendingUpdatesForView(nsView *,bool) [view/nsViewManager.cpp:394]
 02:50:24     INFO -  #15: nsViewManager::ProcessPendingUpdates() [view/nsViewManager.cpp:1101]
 02:50:24     INFO -  #16: mozilla::RefreshDriverTimer::TickDriver(nsRefreshDriver *,__int64,mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:266]
 02:50:24     INFO -  #17: mozilla::RefreshDriverTimer::TickRefreshDrivers(__int64,mozilla::TimeStamp,nsTArray<RefPtr<nsRefreshDriver> > &) [layout/base/nsRefreshDriver.cpp:237]
 02:50:24     INFO -  #18: mozilla::RefreshDriverTimer::Tick(__int64,mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:258]
 02:50:24     INFO -  #19: mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers(mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:568]
 02:50:24     INFO -  #20: mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver(mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:489]
 02:50:24     INFO -  #21: nsRunnableMethodImpl<void ( mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::*)(mozilla::TimeStamp),1,mozilla::TimeStamp>::Run() [xpcom/glue/nsThreadUtils.h:873]
 02:50:24     INFO -  #22: nsThread::ProcessNextEvent(bool,bool *) [xpcom/threads/nsThread.cpp:989]
 02:50:24     INFO -  #23: NS_ProcessNextEvent(nsIThread *,bool) [xpcom/glue/nsThreadUtils.cpp:297]
 02:50:24     INFO -  #24: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate *) [ipc/glue/MessagePump.cpp:95]
 02:50:24     INFO -  #25: MessageLoop::RunInternal() [ipc/chromium/src/base/message_loop.cc:234]
 02:50:24     INFO -  #26: MessageLoop::RunHandler() [ipc/chromium/src/base/message_loop.cc:228]
 02:50:24     INFO -  #27: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:202]
 02:50:24     INFO -  #28: nsBaseAppShell::Run() [widget/nsBaseAppShell.cpp:158]
 02:50:24     INFO -  #29: nsAppShell::Run() [widget/windows/nsAppShell.cpp:259]
 02:50:24     INFO -  #30: nsAppStartup::Run() [toolkit/components/startup/nsAppStartup.cpp:282]
 02:50:24     INFO -  #31: XREMain::XRE_mainRun() [toolkit/xre/nsAppRunner.cpp:4288]
 02:50:24     INFO -  #32: XREMain::XRE_main(int,char * * const,nsXREAppData const *) [toolkit/xre/nsAppRunner.cpp:4385]
 02:50:24     INFO -  #33: XRE_main [toolkit/xre/nsAppRunner.cpp:4487]
 02:50:24     INFO -  #34: do_main [browser/app/nsBrowserApp.cpp:212]
 02:50:24     INFO -  #35: NS_internal_main(int,char * *) [browser/app/nsBrowserApp.cpp:352]
 02:50:24     INFO -  #36: wmain [toolkit/xre/nsWindowsWMain.cpp:138]
 02:50:24     INFO -  #37: __tmainCRTStartup [f:/dd/vctools/crt/crtw32/startup/crt0.c:255]
 02:50:24     INFO -  #38: kernel32 + 0x17067
 02:50:25  WARNING -  TEST-UNEXPECTED-FAIL | file:///C:/slave/test/build/tests/reftest/tests/layout/reftests/webm-video/object-fit-fill-webm-002.html | application terminated with exit code 1
 02:50:29     INFO -  mozcrash INFO | Saved minidump as C:\slave\test\build\blobber_upload_dir\2ea6f33b-aa05-48a2-b2aa-b8216aa0cc08.dmp

That last assertions was mostly seen on Windows 7 debug:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=9f466bb4d8f0
Reporter

Comment 1

4 years ago
Assertion #4:
 2:19.86 [GFX1]: Texture deallocated too late during shutdown
 2:19.86 Assertion failure: false (An assert from the graphics logger), at c:\mozilla-central\gfx\2d\Logging.h:523
 2:19.86 [4440] WARNING: NS_ENSURE_TRUE(context) failed: file c:/mozilla-central/xpcom/threads/nsThread.cpp, line 794
 2:21.46 #01: mozilla::gfx::Log<1,mozilla::gfx::CriticalLogger>::Flush (c:\mozilla-central\gfx\2d\logging.h:297)
 2:21.46 #02: mozilla::gfx::Log<1,mozilla::gfx::CriticalLogger>::~Log<1,mozilla::gfx::CriticalLogger> (c:\mozilla-central\gfx\2d\logging.h:288)
 2:21.46 #03: mozilla::layers::DeallocateTextureClient (c:\mozilla-central\gfx\layers\client\textureclient.cpp:243)
 2:21.46 #04: mozilla::layers::TextureClient::Destroy (c:\mozilla-central\gfx\layers\client\textureclient.cpp:345)
 2:21.47 #05: mozilla::layers::TextureClient::~TextureClient (c:\mozilla-central\gfx\layers\client\textureclient.cpp:440)
 2:21.47 #06: mozilla::layers::TextureClient::`scalar deleting destructor'[xul +0x1a946cf]
 2:21.48 #07: mozilla::AtomicRefCountedWithFinalize<mozilla::layers::TextureClient>::Release (c:\mozilla-central\obj-i686-pc-mingw32\dist\include\mozilla\layers\atomicrefcountedwithfinalize.h:148)
 2:21.48 #08: RefPtr<mozilla::layers::TextureClient>::AddRefTraitsReleaseHelper (c:\mozilla-central\obj-i686-pc-mingw32\dist\include\mozilla\refptr.h:363)
 2:21.48 #09: RefPtr<mozilla::layers::TextureClient>::AddRefTraits<mozilla::layers::TextureClient>::Release (c:\mozilla-central\obj-i686-pc-mingw32\dist\include\mozilla\refptr.h:372)
 2:21.48 #10: RefPtr<mozilla::layers::TextureClient>::~RefPtr<mozilla::layers::TextureClient> (c:\mozilla-central\obj-i686-pc-mingw32\dist\include\mozilla\refptr.h:56)
 2:21.49 #11: mozilla::layers::SharedPlanarYCbCrImage::~SharedPlanarYCbCrImage (c:\mozilla-central\gfx\layers\ipc\sharedplanarycbcrimage.cpp:48)
 2:21.49 #12: mozilla::layers::SharedPlanarYCbCrImage::`scalar deleting destructor'[xul +0x1b656af]
 2:21.49 #13: mozilla::layers::Image::Release (c:\mozilla-central\obj-i686-pc-mingw32\dist\include\imagecontainer.h:189)
 2:21.50 #14: mozilla::FFmpegH264Decoder<55>::ReleaseBufferCb (c:\mozilla-central\dom\media\platforms\ffmpeg\ffmpegh264decoder.cpp:287)
 2:21.52 #15: compat_free_buffer (c:\mozilla-central\media\ffvpx\libavcodec\utils.c:863)
 2:21.53 #16: buffer_replace (c:\mozilla-central\media\ffvpx\libavutil\buffer.c:120)
 2:21.53 #17: av_buffer_unref (c:\mozilla-central\media\ffvpx\libavutil\buffer.c:129)
 2:21.53 #18: compat_release_buffer (c:\mozilla-central\media\ffvpx\libavcodec\utils.c:870)
 2:21.53 #19: buffer_replace (c:\mozilla-central\media\ffvpx\libavutil\buffer.c:120)
 2:21.53 #20: av_buffer_unref (c:\mozilla-central\media\ffvpx\libavutil\buffer.c:129)
 2:21.53 #21: av_frame_unref (c:\mozilla-central\media\ffvpx\libavutil\frame.c:474)
 2:21.53 #22: release_delayed_buffers (c:\mozilla-central\media\ffvpx\libavcodec\pthread_frame.c:324)
 2:21.53 #23: ff_frame_thread_free (c:\mozilla-central\media\ffvpx\libavcodec\pthread_frame.c:597)
 2:21.53 #24: ff_thread_free (c:\mozilla-central\media\ffvpx\libavcodec\pthread.c:85)
 2:21.53 #25: avcodec_close (c:\mozilla-central\media\ffvpx\libavcodec\utils.c:2915)
 2:21.53 #26: mozilla::FFmpegDataDecoder<55>::ProcessShutdown (c:\mozilla-central\dom\media\platforms\ffmpeg\ffmpegdatadecoder.cpp:202)
 2:21.53 #27: nsRunnableMethodArguments<>::apply<mozilla::FFmpegDataDecoder<55>,void (__thiscall mozilla::FFmpegDataDecoder<55>::*)(void)> (c:\mozilla-central\obj-i686-pc-mingw32\dist\include\nsthreadutils.h:664)
 2:21.54 #28: nsRunnableMethodImpl<void (__thiscall mozilla::FFmpegDataDecoder<55>::*)(void),1>::Run (c:\mozilla-central\obj-i686-pc-mingw32\dist\include\nsthreadutils.h:872)
 2:21.54 #29: mozilla::TaskQueue::Runner::Run (c:\mozilla-central\xpcom\threads\taskqueue.cpp:171)
 2:21.54 #30: nsThreadPool::Run (c:\mozilla-central\xpcom\threads\nsthreadpool.cpp:223)
 2:21.55 #31: nsThread::ProcessNextEvent (c:\mozilla-central\xpcom\threads\nsthread.cpp:989)
 2:21.55 #32: NS_ProcessNextEvent (c:\mozilla-central\xpcom\glue\nsthreadutils.cpp:297)
 2:21.55 #33: mozilla::ipc::MessagePumpForNonMainThreads::Run (c:\mozilla-central\ipc\glue\messagepump.cpp:326)
 2:21.56 #34: MessageLoop::RunInternal (c:\mozilla-central\ipc\chromium\src\base\message_loop.cc:235)
 2:21.56 #35: MessageLoop::RunHandler (c:\mozilla-central\ipc\chromium\src\base\message_loop.cc:228)
 2:21.56 #36: MessageLoop::Run (c:\mozilla-central\ipc\chromium\src\base\message_loop.cc:202)
 2:21.56 #37: nsThread::ThreadFunc (c:\mozilla-central\xpcom\threads\nsthread.cpp:403)
 2:21.62 #38: _PR_NativeRunThread (c:\mozilla-central\nsprpub\pr\src\threads\combined\pruthr.c:397)
 2:21.62 #39: pr_root (c:\mozilla-central\nsprpub\pr\src\md\windows\w95thred.c:90)
 2:21.62 #40: _get_flsindex[MSVCR120 +0x2c01d]
 2:21.62 #41: _get_flsindex[MSVCR120 +0x2c001]
 2:21.62 #42: BaseThreadInitThunk[KERNEL32 +0x13744]
 2:21.62 #43: RtlSetCurrentTransaction[ntdll +0x5a064]
 2:21.62 #44: RtlSetCurrentTransaction[ntdll +0x5a02f]
 2:22.24 TEST-UNEXPECTED-FAIL | Shutdown | application terminated with exit code 1
PROCESS-CRASH | Shutdown | application crashed [unknown top frame]
Crash dump filename: c:\users\develo~1\appdata\local\temp\tmprwcmmy.mozrunner\minidumps\d087c605-83a6-4423-97ea-ca65a3b05f68.dmp
MINIDUMP_STACKWALK not set, can't process dump.
 2:22.24 TEST-INFO | leakcheck | default process: leak threshold set at 0 bytes

This one I can reproduce locally, and is unique to how the ffmpeg PDM works ; using the gfx stack to allocate buffers. We should probably let ffmpeg do it like we let libvpx manage its own memory
Reporter

Updated

4 years ago
Depends on: 1236384
Reporter

Updated

4 years ago
No longer depends on: 1236384
Reporter

Comment 2

4 years ago
:nical

I haven't managed to reproduce locally #1, #2 nor #3 (#4 is fixed by bug 1236384)

All other crashes are D3D9 related. Unfortunately, I can't reproduce it locally. I try setting layers.prefer-d3d9 to true (did so in module/libpref/init/all.js to ensure that ./mach reftest or mochitest would be affected)
however when doing so I never enter the D3D9 compositor code path.

when prefer-d3d9 is set to true, about:support shows:
Direct2D Enabled: Blocked for your graphics card because of unresolved driver issues.
GPU Accelerated Windows: 0/1 Basic (OMTC) Blocked for your graphics card because of unresolved driver issues.

which is probably related

I'm using a Windows 10 VM (32 bits firefox), VMWare Fusion 8.1 that supposedly supports DirectX 10 and OpengGL 3.3.
Any chance on getting D3D9 working with VMWare ?

If not, I'll set a real PC under Win 7 tomorrow. Just looking at the code make my brain overflow trying to follow the architecture and how surface flows around
Flags: needinfo?(nical.bugzilla)
(In reply to Jean-Yves Avenard [:jya] from comment #0)

For the first crash, I think what's happening is that we don't check the return value of AllocSurfaceDescriptor in ClientLayerManager::MakeSnapshotIfRequired (but we should!). The allocation fails (is this while shutting down? Could also be an invalid size or just an OOM), and the call to DestroySharedSurface which expects a SurfaceDescriptorBuffer gets the default empty SurfaceDecriptor hence the assertion you run into.
It would be better to check the result of AllocSurfaceDescriptor, even if it is followed by a release assert, so that the cause of the crash is more obvious. I'll put a quick patch up which will make it still crash but at least in a more understandable way.
(In reply to Jean-Yves Avenard [:jya] from comment #2)
> I'm using a Windows 10 VM (32 bits firefox), VMWare Fusion 8.1 that
> supposedly supports DirectX 10 and OpengGL 3.3.
> Any chance on getting D3D9 working with VMWare ?

I'll have a look, not sure though. GPU stuff in emulators tend to not work well, but I think there is some way to disable the driver block list and see what works. DirectD2D is only enabled when D3D11 compositing is enabled so that part is expected.

> If not, I'll set a real PC under Win 7 tomorrow. Just looking at the code
> make my brain overflow trying to follow the architecture and how surface
> flows around

Yeah, a lot of awfulness in there. I'm happy to help if you have questions about the architecture, and Matt Woodrow, who lives in a timezone friendlier to yours also knows that stuff pretty well.
Flags: needinfo?(nical.bugzilla)
For Assertion #2, my intuition is that GetDrawTargetForDescriptor in CompositorParent::RecvMakeSnapshot return a null DrawTarget, and that we should null-check it. Perhaps a symptom of something that went wrong on the client side like assertion #1, and we end up with an invalid size when creating the DrawTarget, best to add a release assert here to be sure.

Assertion #3 is in some of my all time least favorite code, and it's kinda surprising that video changes would break something there (it's in some drawing layer code that video don't use), unless it is causing us to run out of memory, which is typically the cause for the warnings logged before the crash.
Off hands I don't have the "proper" way to force a blocklisted configuration like d3d9 on vmware but if you are making your own build you can just make gfxPlatform::CanUseD3D9() always return true. AFAIK all code that needs to know whether d3d9 is enabled will read this or something that depends on this, except the information in about:support which (I think) is read from the blocklist code in GfxInfo, so you'd have the possibility to enable d3d9 with the pref even though about:support would still report it as blocked.
It may be completely unusable, obviously.
This should make the few crashes related to MakeSnapshot either go away or move closer to their cause.
With SendMakeSnapshot it appears that we'd call DestroySharedSurface even if AllocSurfaceDescriptor never ran or failed so my patch may hide the crash and the underlying issue by just not having the snapshot taken, probably not good enough.
I suggest checking that bounds.IsEmpty() is not specifically returning false with the ffmpeg patches (that would be the cause of the regression). I suppose it currently never happens without the patches or not enough for us to notice it.
Attachment #8703686 - Flags: review?(bgirard)
(In reply to Nicolas Silva [:nical] from comment #3)
> For the first crash, I think what's happening is that we don't check the
> return value of AllocSurfaceDescriptor in
> ClientLayerManager::MakeSnapshotIfRequired

In fact we do, but we try to deallocate the surface even if it failed or if we didn't call it which is just as bad.
Comment on attachment 8703686 [details] [diff] [review]
Avoid issues with Send/RecvMakeSnapshot

empty patch
Attachment #8703686 - Flags: review?(bgirard)
Reporter

Comment 11

4 years ago
hmmm bz didn't attach my comment.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2ae93e804cfe
Patch 1 fixes crash #1. Instead we have timeouts.

The original reason we got there appears to be related to the error "GFX3-]: DrawTargetSkia(167AB100): Failure to create source surface from data. Size: Size(800,1000) "
Reporter

Updated

4 years ago
See Also: → 1236746
Reporter

Comment 12

4 years ago
(In reply to Nicolas Silva [:nical] from comment #3)
> (In reply to Jean-Yves Avenard [:jya] from comment #0)
> 
> For the first crash, I think what's happening is that we don't check the
> return value of AllocSurfaceDescriptor in
> ClientLayerManager::MakeSnapshotIfRequired (but we should!). The allocation
> fails (is this while shutting down? Could also be an invalid size or just an
> OOM), and the call to DestroySharedSurface which expects a
> SurfaceDescriptorBuffer gets the default empty SurfaceDecriptor hence the
> assertion you run into.
> It would be better to check the result of AllocSurfaceDescriptor, even if it
> is followed by a release assert, so that the cause of the crash is more
> obvious. I'll put a quick patch up which will make it still crash but at
> least in a more understandable way.

I had missed that you posted a patch. I guess I should have assigned that bug to me to avoid another conflict and us working on the same stuff (it has happened before :) )

I had completed it yesterday but was waiting on a try run to complete before posting for review. I came to the same conclusion as you on why we hit #1.

For crash #2, I can't see any particular previous error in the log that is symptomatic of the null-deref

Crash #3, happens when we can't allocate a D3D9 texture ([1112] WARNING: Could not create a d3d9 texture: file c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/src/gfx/layers/d3d9/TextureD3D9.cpp, line 471). So you're thinking this could be an OOM issue ??
Reporter

Updated

4 years ago
Attachment #8703686 - Attachment is obsolete: true
Reporter

Comment 13

4 years ago
I got a win7 32 bits VM DirectX 9 and opengl 2.1 support only, installed a debug build, opened youtube, seeing hundreds of error in the log such as:

[Parent 3388] WARNING: '!temp', file c:/builds/moz2_slave/try-w32-d-000000000000
00000000/build/src/gfx/layers/basic/BasicCompositor.cpp, line 481
[GFX3-]: Surface width or height <= 0!
[GFX3-]: Surface width or height <= 0!
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: Failed to allocate a surfac
e due to invalid size (DSS) Size(0,0)|[11][GFX1-]: Failed to allocate a surface
due to invalid size (DSS) Size(0,0)|[12][GFX1-]: Failed to allocate a surface du
e to invalid size (DSS) Size(0,0)|[13][GFX1-]: Failed to allocate a surface due
to invalid size (DSS) Size(0,0)|[14][GFX1-]: Failed to allocate a surface due to
 invalid size (DSS) Size(0,0)|[10][GFX1-]: Failed to allocate a surface due to i
nvalid size (DSS) Size(0,0)[GFX1-]: Failed to allocate a surface due to invalid
size (DSS) Size(0,0)
[Parent 3388] WARNING: '!temp', file c:/builds/moz2_slave/try-w32-d-000000000000
00000000/build/src/gfx/layers/basic/BasicCompositor.cpp, line 481
[GFX3-]: Surface width or height <= 0!
[GFX3-]: Surface width or height <= 0!

is this expected?
Attachment #8703870 - Flags: review?(nical.bugzilla) → review+
(In reply to Jean-Yves Avenard [:jya] from comment #12)
> I had missed that you posted a patch. I guess I should have assigned that
> bug to me to avoid another conflict and us working on the same stuff (it has
> happened before :) )

No problem, I was just posting a patch to move crashes to more useful stack traces and fix the poor handling of DeallocateSharedSurface so as to help with debugging but the patch wasn't answering the underlying question "why did we always succeed to make the snapshot and now we get into the branches where we fail (and didn't handle failure properly)?". I guess the root cause is going to be the same as the failure to initialize 0-sized surfaces.

It is expected that allocating surfaces of size 0 by 0 fails, but not that we attempt to do that in the first place. Do you know what kind of Image class is used with this particular test case/platform/decoder? If you can repro locally it's worth looking at where the empty sizes come from.
Reporter

Comment 15

4 years ago
Images causing the failure are created here:
https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegH264Decoder.cpp#210

There are VideoData::YCbCrBuffer, plain YUV420 images.

In the log showed in commit 13 with allocation of 0 by 0, that was the h264 decoder at the time, so the WMF h264 software decoder, so that would be there:
https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/wmf/WMFVideoMFTManager.cpp#434
also similar to YUV420 (originally windows type is MFVideoFormat_YV12, so same as YUV420 with U and V plans switched)

However, in commit 13 I saw them going to youtube.com and before playing any videos.

In windows 7, all the crashes are following a failure to initialise the ffmpeg vp8 decoder. I haven't been able to reproduce that on either win7 64 bits (a real dell PC) nor a 32 bits VM

I think for the time being I will disable VP8 decoding using ffmpeg so that allows me to land.. But still need to track what's going on here.
The part of the my previous patch that was not in Jean-Yves's (and actually I uploaded an empty patch yesterday so that one's more useful). It doesn't fix the issue(s), but makes sure we don't go deep in the compositor snapshotting logic if the inputs received by the compositor thread aren't valid. This is purely to make the error easier to recognize if it happens again, but doesn't fix anything. A bit too small (and me a bit too lazy) to create a separate bug for.
Attachment #8704112 - Flags: review?(jmuizelaar)
Reporter

Comment 17

4 years ago
here is the try run with patch "move the RecvSnapShot crashes to a more meaningful stack trace"
https://treeherder.mozilla.org/#/jobs?repo=try&revision=650c5db997bf
Actually, the warning "Failed to allocate a surface due to invalid size" is only in code that deals with rgb kind of surfaces, so it might not be related to video unless this is happening on the compositor if the latter needs to convert yuv frames to rgb (only the basic compositor does that) but then you'd have some other warnings in the log systematically following this one.

"[Parent 3388] WARNING: '!temp', file gfx/layers/basic/BasicCompositor.cpp, line 481" is not realted to video either (though it seems to indicate that you are using the basic compositor rather than d3d9, in case that was not your intention).
Attachment #8704112 - Flags: review?(jmuizelaar) → review+
Reporter

Comment 19

4 years ago
Still getting crashes, always assertion #3 now:
 08:44:59     INFO -  ??????????p: N[GFX2-]: ASurface Init failed with Cairo status 1 on 0x66D7DDD8
 08:44:59     INFO -  [1264] WARNING: Could not create DIB surface: file c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/src/gfx/layers/TextureDIB.cpp, line 171
 08:44:59     INFO -  [GFX3-]: BufferTextureData: Failed to allocate 3200000 bytes
 08:44:59     INFO -  [GFX1]: Failed 2 buffer db=0x00000000 dw=0x00000000 for 0, 0, 800, 1000
 08:44:59     INFO -  Assertion failure: false (An assert from the graphics logger), at c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\src\gfx\2d\Logging.h:523
 08:44:59     INFO -  #01: mozilla::gfx::Log<1,mozilla::gfx::CriticalLogger>::Flush() [gfx/2d/Logging.h:297]
 08:44:59     INFO -  #02: mozilla::layers::RotatedContentBuffer::BeginPaint(mozilla::layers::PaintedLayer *,unsigned int) [gfx/layers/RotatedBuffer.cpp:674]
 08:44:59     INFO -  #03: mozilla::layers::ContentClientRemoteBuffer::BeginPaintBuffer(mozilla::layers::PaintedLayer *,unsigned int) [gfx/layers/client/ContentClient.h:218]
 08:44:59     INFO -  #04: mozilla::layers::ClientPaintedLayer::PaintThebes() [gfx/layers/client/ClientPaintedLayer.cpp:66]

Now for the interesting part. I disabled FFmpeg's VP8 decoder on windows 7 and windows XP in this try run:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=3d38e5cf9623

That means we're now back to using libvpx (same as always): yet I get exactly the same assertion failure in gfx! So it's got nothing to do with ffmpeg, something must have changed the timing of things exposing the problem :(
going to be even harder to track.
Reporter

Comment 20

4 years ago
ah no my bad... it's a vp9 video in there. I had only disabled vp8.
Reporter

Comment 21

4 years ago
In the log the "WARNING: Couldn't initialise ffmpeg decoder" is really "couldn't alloc codec context". The only thing that code does there is allocate 982 bytes on a 32 bytes boundary... It's an OOM (or there's something screwed in the ffmpeg's aligned malloc on win7).

That doesn't explain the timeout on XP nor why we also assert in gfx after.
Reporter

Comment 22

4 years ago
(In reply to Jean-Yves Avenard [:jya] from comment #21)
> In the log the "WARNING: Couldn't initialise ffmpeg decoder" is really
> "couldn't alloc codec context". The only thing that code does there is
> allocate 982 bytes on a 32 bytes boundary... It's an OOM (or there's
> something screwed in the ffmpeg's aligned malloc on win7).
my bad again, I was looking at the wrong place in the code... so it's not OOM. will request access to that machine. can't reproduce it locally.
Reporter

Comment 23

4 years ago
Ok... I've managed to reproduce the FFmpeg init failure locally.

I added printf to find out what was going on in ffmpeg, for each potential errors where avcodec_open2 could fail.
When it fails on my mac, I see:
 1:22.40 avcodec_open2: Failed initialising threads[69084] WARNING: Couldn't initialise ffmpeg decoder (error: -35) current thread_count:1952: file /Users/jyavenard/Work/Mozilla/mozilla-central/dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp, line 127

-35 is -EAGAIN, which is almost certainly the result of pthread_create meaning "The system lacked the necessary resources to create another thread, or the system-imposed limit on the total number of threads in a process [PTHREAD_THREADS_MAX] would be exceeded."

the layout/reftest for example, some of them open 21 video elements at once. The winXP/win7 machines are quad-core, 8 threads CPU. So for each video element it uses 8 threads, so a single reftest is already using 168 threads.
That's just one test!

the way we configure libvpx is based on the dimensions of the video, a video < 1024p will only use a maximum of 2 threads, <= 1024p a maximum of 8 and >= 2k max of 8.

This is a red-herring related to the above crashes however, as I get those crashes even without ffmpeg failing to initialise. It just happens to happen more often.
Now it could always be the same related cause: too many threads at once.
On top of that, I don't know how the stack size works and if it's affected by the 256kB limit we impose, but on windows I read that the default is 1MB per thread.

Adding my fprintf removed all failures on Windows XP, so I could always use that as a workaround ! :)
Reporter

Updated

4 years ago
Summary: Various gfx crashes/assertions when using ffvp8 decoder → Various gfx crashes/assertions when using ffvp8 or ffvp9 decoder
Reporter

Comment 24

4 years ago
Ronald, could you suggest a reasonable algorithm in regards on how to make the best use of threads with ffvp9 ?

The default is to use the number of cores for a single decoder, in our regression tests where we open hundreds of video elements at once (webm/vp9) this appears to make us hit the system limit (or OOM) very quickly.

With libvpx, we used the same logic as chrome:
https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/agnostic/VPXDecoder.cpp#60

That is:
min(height <= 1024 ? 2 : height >= 2048 ? 8 : 4 , num_cores)

Do you think this would give acceptable performance with ffvp9 ?
In your white paper (https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/), it shows that performance appears as increasing linearly according to the number of threads. Unfortunately, it only shows data for 4 threads.
Flags: needinfo?(rsbultje)
(In reply to Jean-Yves Avenard [:jya] from comment #19)
> Still getting crashes, always assertion #3 now:
>  08:44:59     INFO -  ??????????p: N[GFX2-]: ASurface Init failed with Cairo
> status 1 on 0x66D7DDD8
>  08:44:59     INFO -  [1264] WARNING: Could not create DIB surface: file
> c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/src/gfx/layers/
> TextureDIB.cpp, line 171
>  08:44:59     INFO -  [GFX3-]: BufferTextureData: Failed to allocate 3200000
> bytes
>  08:44:59     INFO -  [GFX1]: Failed 2 buffer db=0x00000000 dw=0x00000000
> for 0, 0, 800, 1000
>  08:44:59     INFO -  Assertion failure: false (An assert from the graphics
> logger), at
> c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\src\gfx\2d\Logging.
> h:523
>  08:44:59     INFO -  #01:
> mozilla::gfx::Log<1,mozilla::gfx::CriticalLogger>::Flush()
> [gfx/2d/Logging.h:297]
>  08:44:59     INFO -  #02:
> mozilla::layers::RotatedContentBuffer::BeginPaint(mozilla::layers::
> PaintedLayer *,unsigned int) [gfx/layers/RotatedBuffer.cpp:674]
>  08:44:59     INFO -  #03:
> mozilla::layers::ContentClientRemoteBuffer::BeginPaintBuffer(mozilla::layers:
> :PaintedLayer *,unsigned int) [gfx/layers/client/ContentClient.h:218]
>  08:44:59     INFO -  #04:
> mozilla::layers::ClientPaintedLayer::PaintThebes()
> [gfx/layers/client/ClientPaintedLayer.cpp:66]

All of these gfx failures are indeed typically caused by OOMs.
Reporter

Updated

4 years ago
See Also: → 1237210
Reporter

Comment 26

4 years ago
Following The change un but 1237210, mo more crashes and it looks like it's going to be all green. 
Nicolas could make a fix to prevent the null deref?

Better timing out/erroring than crashing!

Comment 27

4 years ago
Hi Jean-Yves, yes I think that would work fine. The ffmpeg default is really intended for single-video users. Chrome overrides it too, if I remember correctly.
Flags: needinfo?(rsbultje)
Reporter

Comment 28

4 years ago
Correction, libvpx thread count is based on the *width*, not the height surprisingly enough..
Reporter

Comment 29

4 years ago
Interestingly, on win7, failure to create a thread occurs with thread count ~750
on windows XP it's ~1300 (though you usually get a null deref in gfx before that)
(In reply to Jean-Yves Avenard [:jya] from comment #29)
> Interestingly, on win7, failure to create a thread occurs with thread count
> ~750
> on windows XP it's ~1300 (though you usually get a null deref in gfx before
> that)

You mean assertion #2 ? the patch I posted takes care of that. Other crashes related to OOMs are trickier because as soon as you patch up one place it blows up somewhere else, and usually if there is no way to allocate any texture we are better off crashing than having a completely unusable browser that don't draw anything (at least we have some crash stats and the user gets to restart the browser in a sane state).
Reporter

Comment 32

4 years ago
I still get null deref like here:
https://treeherder.mozilla.org/logviewer.html#?job_id=15120294&repo=try

This is in the D3D9 compositor
(In reply to Jean-Yves Avenard [:jya] from comment #32)
> I still get null deref like here:
> https://treeherder.mozilla.org/logviewer.html#?job_id=15120294&repo=try
> 
> This is in the D3D9 compositor

hm, ok, looking into it.
Whiteboard: [leave-open]
Keywords: crash
What combination of patches / prefs do I need to reproduce the remaining gfx crashes? Looks like the patches in bug 1214462 landed and media.ffmpeg.enabled is true by default on central.
Flags: needinfo?(jyavenard)
Reporter

Comment 37

4 years ago
revert http://hg.mozilla.org/mozilla-central/rev/84db9e4cf212

and run:
./mach reftest

I could reproduce the decoding failure with just ./mach reftest layout/reftest/webm-video

but not the crashes or than in try.
this is the last try run I had that crashed fairly consistently
https://treeherder.mozilla.org/#/jobs?repo=try&revision=ade43bab678f
Flags: needinfo?(jyavenard)
Reporter

Updated

3 years ago
Blocks: 1235264
Whiteboard: [leave-open] → [leave-open] gfx-noted
Keywords: leave-open
Whiteboard: [leave-open] gfx-noted → gfx-noted

The leave-open keyword is there and there is no activity for 6 months.
:jbonisteel, maybe it's time to close this bug?

Flags: needinfo?(jbonisteel)

All happening on Windows XP or Vista [..]

Let's close it.

Status: NEW → RESOLVED
Closed: 4 months ago
Flags: needinfo?(jbonisteel)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.