New issue
Advanced search Search tips

Issue 898600 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 898842
Owner:
Closed: Oct 26
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

depth_capture_tests GPU tests failing on Android FYI Release (Nexus 9)

Project Member Reported by ccameron@chromium.org, Oct 24

Issue description

We're seeing the following tests intermittently failing on Android FYI Release (Nexus 9).
- depth_capture_tests

The first failure is in this build
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Android%20FYI%20Release%20%28Nexus%209%29/9399

But there is not a clear culprit CL. The failure appears to be with the following crash
    // If you hit this DCHECK, your dump provider has a bug.
    // Unregistration of a MemoryDumpProvider is safe only if:
    // - The MDP has specified a sequenced task runner affinity AND the
    //   unregistration happens on the same task runner. So that the MDP cannot
    //   unregister and be in the middle of a OnMemoryDump() at the same time.
    // - The MDP has NOT specified a task runner affinity and its ownership is
    //   transferred via UnregisterAndDeleteDumpProviderSoon().
    // In all the other cases, it is not possible to guarantee that the
    // unregistration will not race with OnMemoryDump() calls.
[FATAL:memory_dump_manager.cc(251)] Check failed: (*mdp_iter)->task_runner && (*mdp_iter)->task_runner->RunsTasksInCurrentSequence(). MemoryDumpProvider "ContextProviderCommandBuffer" attempted to unregister itself in a racy way. Please file a crbug.

base::trace_event::MemoryDumpManager::UnregisterDumpProviderInternal
ws::ContextProviderCommandBuffer::~ContextProviderCommandBuffer
base::internal::Invoker...

Sending to ericrk as a first peak (it may be that I'm mis-reading which test is crashing, so please double-check that -- Android logs are messy).

 
This DCHECK should only be hit if we are destroying the ContextProviderCommandBuffer on a thread other than the one it was initially bound on.

Once the ContextProviderCommandBuffer is bound on a given thread, several peices of code (CommandBufferProxyImpl, ContextCacheController, MemoryDumpProvider) all hold that thread's task runner and use it to work with the context. Destroying the context on a different thread will be racy.

We probably should have had a better DCHECK for this in the constructor. I'll add one now.

Mergedinto: 898842
Status: Duplicate (was: Available)
See also crbug.com/899395

Sign in to add a comment