1285238 - Intermittent LeakSanitizer | leak at mozilla::layers::BufferTextureData::CreateInternal, mozilla::layers::BufferTextureData::CreateForYCbCr, mozilla::layers::TextureClient::CreateForYCbCr, mozilla::layers::YCbCrTextureClientAllocationHelper::Allocate

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Treeherder Bug Filer]

Filed by: tomcat

https://treeherder.mozilla.org/logviewer.html#?job_id=355751&repo=autoland

http://archive.mozilla.org/pub/firefox/tinderbox-builds/autoland-linux64-asan/1467887841/autoland_ubuntu64-asan_vm_test-mochitest-clipboard-bm117-tests1-linux64-build39.txt.gz

Comment 1

[Bas Schouten (:bas.schouten)]

This looks like there's a race condition during shutdown causing this leak. Nical, is there anything we can do on our side about this? (See the log's gfxCriticalError)

Comment 2

[Nicolas Silva [:nical]]

We already try to mitigate this type of situation by forcing all textures to be destroyed synchronously when shutting down our ipdl protocols. Doing that is not race-free unfortunately, and making that completely race-free is hard, so it can happen that textures fall through the cracks and don't get destroyed syncrhonously with the ImageBridge. The issue here is that the destruction of the texture is happening very late when the ImageBridge thread itself (not just the protocols) is already gone. Papering over this is hard. The most sensible way to fix this is to identify what is releasing the texture so late and make sure it is cleaned up during media or gfx's shutdown. Unfortunately there is no stack for the gfxCriticalError in the log so I my guess would be to start looking at the TextureClientRecycleAllocator that was added recently-ish and may not be dealing with shutdown explicitly.

Comment 3

[Nicolas Silva [:nical]]

Sotaro, is there an explicit mechanism to make sure the recycling mechanism for video texture is shut down before the gfx IPDL protocols? In particular I am looking at CompositableClient::mTextureClientRecycler which seems to rely only on reference counting and it is probably not enough to have the recycler reliably cleaned up in time.

Comment 4

[Sotaro Ikeda [:sotaro]]

(In reply to Nicolas Silva [:nical] from comment #3)
> Sotaro, is there an explicit mechanism to make sure the recycling mechanism
> for video texture is shut down before the gfx IPDL protocols?

There is not explicit mechanism now. I am going to add it.

Comment 5

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Add TextureClientRecycleAllocator::Destroy()

Comment 6

[Sotaro Ikeda [:sotaro]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=360df2dc42b6&selectedJob=23859616

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0659b2021265
Add TextureClientRecycleAllocator::Destroy() r=nical

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0659b2021265