Closed Bug 1175903 Opened 9 years ago Closed 3 years ago

Crash seen in Firefox stack trace (windbg/IDA) showing ContentClientDoubleBuffered::FinalizeFrame

Categories

(Core :: Graphics: Layers, defect)

38 Branch
x86_64
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: akhileshsp1, Unassigned)

References

Details

(Keywords: crash, stackwanted, Whiteboard: gfx-noted)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36 Steps to reproduce: Occasionally Firefox seems to be crashing, I'm not sure how to reproduce. Actual results: Firefox crashed. Looking at source code of FF 38.0.6, I see in file ContentClient.cpp line 593, we see something like: RefPtr<SourceSurface> surf = mFrontClient->BorrowDrawTarget()->Snapshot(); It seems BorrowDrawTarget() returned NULL which caused the crash! Expected results: It should not crash.
Severity: normal → critical
Component: Untriaged → Graphics: Layers
Keywords: crash, stackwanted
OS: Unspecified → Windows 7
Product: Firefox → Core
Hardware: Unspecified → x86_64
While we're waiting, BorrowDrawTarget() can return nullptr, and we are not protecting all the places where those calls are made. Jeff, can you get Kyle or Andrew to find these places and "do the right thing" (may have to consult with different people as to what that right thing is.)
Flags: needinfo?(jmuizelaar)
Just FYI this was on a Windows 10 system which doesn't seem to have system dll symbols. The full windbg output is: STACK_TEXT: 008fe6a4 7270212e 008fe860 008fe988 741a6190 xul!mozilla::layers::ContentClientDoubleBuffered::FinalizeFrame+0xc1 008fe8c4 727012b2 008fe920 1f9b9400 00000004 xul!mozilla::layers::RotatedContentBuffer::BeginPaint+0x261 008fe8d4 72634a77 008fe920 1f9b9400 00000004 xul!mozilla::layers::ContentClientRemoteBuffer::BeginPaintBuffer+0x14 008fe958 72634949 00000000 1f9b9400 00000008 xul!mozilla::layers::ClientPaintedLayer::PaintThebes+0x78 008fe994 728f7026 008fe9ac 00000002 1f66e000 xul!mozilla::layers::ClientPaintedLayer::RenderLayerWithReadback+0x7a 008fe9f0 7273f778 728f7026 008fea0c 10982d90 xul!mozilla::layers::ClientContainerLayer::RenderLayer+0xa4 008fe9f4 728f7026 008fea0c 10982d90 10f26e00 xul!mozilla::layers::ClientLayer::RenderLayerWithReadback+0x5 008fea50 728f4748 10982d90 10982d90 10f26c00 xul!mozilla::layers::ClientContainerLayer::RenderLayer+0xa4 008feac4 728f459b 72572443 008fefe8 0cbeb400 xul!mozilla::layers::ClientLayerManager::EndTransactionInternal+0xd0 008feb04 7275ab69 72572443 008fefe8 00000000 xul!mozilla::layers::ClientLayerManager::EndTransaction+0x2b 008fece0 728ce380 008fedec 008fefe8 00000000 xul!nsDisplayList::PaintRoot+0x43c 008ff3dc 72564ee6 008ff4b8 00000000 00000304 xul!nsLayoutUtils::PaintFrame+0x56c 008ff48c 72561e88 0cc6b7e0 008ff4b8 00000001 xul!PresShell::Paint+0x14c 008ff4cc 7256208d 0cbeb400 00000010 0bf9b970 xul!nsViewManager::ProcessPendingUpdatesPaint+0xbe 008ff4f0 72561b7f 0cc6b7e0 00000001 09177a38 xul!nsViewManager::ProcessPendingUpdatesForView+0xb9 008ff508 72749f3a 008ff698 008ff6e0 3a4721e1 xul!nsViewManager::ProcessPendingUpdates+0x35 008ff670 72748b41 3a4721e1 000518c9 015c7d90 xul!nsRefreshDriver::Tick+0x6b6 008ff6b8 72748256 3a4721e1 000518c9 015c7d90 xul!mozilla::RefreshDriverTimer::Tick+0xbd 008ff718 726ba7eb 0ba26740 0ba266d0 00e40160 xul!mozilla::RefreshDriverTimer::TimerTick+0x97 008ff808 729cea53 00e41044 00000000 00002710 xul!nsTimerImpl::Fire+0x1a2 008ff83c 726bcbb7 0c487a88 00e10aa0 00e10a90 xul!nsTimerEvent::Run+0x37 008ff95c 726bb3d7 00e40160 00000000 008ff994 xul!nsThread::ProcessNextEvent+0x736 008ff98c 726bb01d 00e7a001 c511a01e 00e41040 xul!mozilla::ipc::MessagePump::Run+0x5f 008ff9c4 726bae3d 00e40160 00000001 7284ca00 xul!MessageLoop::RunHandler+0x20 008ff9e4 726bd80e 0966f3c0 00000000 726be947 xul!MessageLoop::Run+0x19 008ff9f0 726be947 00e41040 0966f3c0 7299a831 xul!nsBaseAppShell::Run+0x32 008ff9fc 7299a831 00e41040 008ffc7d 0bc7e0e0 xul!nsAppShell::Run+0x1b 008ffa0c 7289a3b0 0966f3c0 008ffb84 008ffba0 xul!nsAppStartup::Run+0x20 008ffaec 7289b29f 00000001 008ffcc8 00e42160 xul!XREMain::XRE_mainRun+0x487 008ffb08 72a7a0ff 00000000 00ba1b90 008ffc00 xul!XREMain::XRE_main+0x1b6 008ffc80 00101635 00000001 00ba1b90 008ffcc8 xul!XRE_main+0x3e 008ffe14 001012dc 00e42160 00ba0530 00001660 firefox!do_main+0x125 008ffeac 001010dc 008fff08 00102521 008fff08 firefox!NS_internal_main+0xec 008ffec0 001024a4 00ba1b90 00ba6828 00ba1af0 firefox!wmain+0xbc 008fff08 752b3224 fea6f000 752b3200 25707073 firefox!__tmainCRTStartup+0xfe WARNING: Stack unwind information not available. Following frames may be wrong. 008fff1c 77a3fa14 fea6f000 d13d8d90 00000000 kernel32+0x13224 008fff64 77a3f9df ffffffff 77a59d42 00000000 ntdll+0x5fa14 008fff74 00000000 00102521 fea6f000 00000000 ntdll+0x5f9df EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s. EXCEPTION_PARAMETER1: 00000000 EXCEPTION_PARAMETER2: 00000000 READ_ADDRESS: 00000000 FOLLOWUP_IP: xul!mozilla::layers::ContentClientDoubleBuffered::FinalizeFrame+c1 [c:\builds\moz2_slave\rel-m-beta-w32_bld-00000000000\build\gfx\layers\client\contentclient.cpp @ 588] 7264ab4d 8b10 mov edx,dword ptr [eax] APP: firefox.exe ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre
Thanks. If there is no crash report, could you also attach about:support graphics section?
The conversation about why protect against BorrowDrawTarget() returning nullptr. Assuming this is a D3D11 scenario, Factory::CreateDrawTargetForD3D11Texture() can return nullptr, assuming we don't get an error elsewhere.
OS: Windows 7 → Windows 10
Here is the contents of that section: Graphics Adapter Description VMware SVGA 3D Adapter Drivers vm3dum64 vm3dum Adapter RAM 1024 Asynchronous Pan/Zoom none Device ID 0x0405 Direct2D Enabled Blocked for your graphics card because of unresolved driver issues. DirectWrite Enabled false (10.0.10074.0) Driver Date 7-29-2014 Driver Version 8.14.1.51 GPU #2 Active false GPU Accelerated Windows 2/2 Direct3D 11 WARP (OMTC) Subsys ID 040515ad Vendor ID 0x15ad WebGL Renderer Blocked for your graphics card because of unresolved driver issues. windowLayerManagerRemote true AzureCanvasBackend skia AzureContentBackend cairo AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0
With D3D11, BorrowDrawTarget will always succeed if the TextureClient was locked successfully (with the write flag, but there is no reason to borrow a DrawTarget after a read-only lock). In this bug the Lock() call is failing and we should be doing something about it.
Marking this bug as NEW based on comment 7. Nicolas, is this bug still waiting for bug 1176024?
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Whiteboard: [@ mozilla::layers::ContentClientDoubleBuffered::FinalizeFrame ]
Chances are, it's actually a duplicate of bug 1200021. (In reply to Nicolas Silva [:nical] from comment #7) > With D3D11, BorrowDrawTarget will always succeed if the TextureClient was > locked successfully (with the write flag, but there is no reason to borrow a > DrawTarget after a read-only lock). In this bug the Lock() call is failing > and we should be doing something about it. See https://bugzilla.mozilla.org/show_bug.cgi?id=1200021#c37 - I'm not sure we can claim that BorrowDrawTarget always succeeds, because we sometimes have to use DrawTargetCairo when in the D3D11 world, and that can fail.
Flags: needinfo?(jmuizelaar)
(In reply to Milan Sreckovic [:milan] from comment #9) > Chances are, it's actually a duplicate of bug 1200021. > > (In reply to Nicolas Silva [:nical] from comment #7) > See https://bugzilla.mozilla.org/show_bug.cgi?id=1200021#c37 - I'm not sure > we can claim that BorrowDrawTarget always succeeds, because we sometimes > have to use DrawTargetCairo when in the D3D11 world, and that can fail. To phrase it differently if Lock(OpenMode::OPEN_WRITE) returned true on a D3D11 TextureClient, then susbequent calls to BorrowDrawTarget always return a non-null DrawTarget, because BorrowDrawTarget is called during Lock and caches the DrawTarget. Lock will fail if the initial BorrowDrawTarget failed and the next calls to BorrowDrawTarget just return the cached DrawTarget. I meant "succeed" in that it will return a DT that is not null, but there was no way to check that the returned DT is in a valid state. I see that your patch on bug 1200021 adds an IsValid method to DrawTarget to check that the DT is not in an unusable state. I'll add a check in BorrowDrawTarget that the target is valid after it lands.

Closing this bug as resolved:WFM given there were no crashes with this Signature in the last 6 months.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.