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

NEW
Unassigned

Status

()

Core
Graphics: Layers
--
critical
3 years ago
3 years ago

People

(Reporter: akhileshsp1, Unassigned)

Tracking

(Blocks: 1 bug, {crash, stackwanted})

38 Branch
x86_64
Windows 10
crash, stackwanted
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: gfx-noted)

(Reporter)

Description

3 years ago
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.

Comment 1

3 years ago
Please post the link to the relevant crash report:
https://developer.mozilla.org/en-US/docs/How_to_get_a_stacktrace_for_a_bug_report
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)
Whiteboard: gfx-noted
(Reporter)

Comment 3

3 years ago
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.
Blocks: 1148406
OS: Windows 7 → Windows 10
(Reporter)

Comment 6

3 years ago
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
Depends on: 1176024
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

Updated

3 years ago
QA Whiteboard: [@ mozilla::layers::ContentClientDoubleBuffered::FinalizeFrame ]
See Also: → bug 1200021
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)
See Also: → bug 1216909
(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.
You need to log in before you can comment on or make changes to this bug.