Issue metadata
Sign in to add a comment
|
MediaEngagementAutoplayBrowserTest.UsePreloadedData_Allowed is flaky |
||||||||||||||||||||||||||
Issue descriptionSample failed build due to flakiness: https://ci.chromium.org/buildbot/chromium.chromiumos/linux-chromeos-dbg/7785 Culprit (70.0% confidence): https://chromium-review.googlesource.com/q/Ide12cb6cebc9dea83a7686c09e6688537bf3389a Analysis: https://findit-for-me.appspot.com/waterfall/flake?key=ag9zfmZpbmRpdC1mb3ItbWVy2QELEhdNYXN0ZXJGbGFrZUFuYWx5c2lzUm9vdCKiAWNocm9taXVtLmNocm9taXVtb3MvbGludXgtY2hyb21lb3MtZGJnLzc3ODUvc2luZ2xlX3Byb2Nlc3NfbWFzaF9icm93c2VyX3Rlc3RzL1RXVmthV0ZGYm1kaFoyVnRaVzUwUVhWMGIzQnNZWGxDY205M2MyVnlWR1Z6ZEM1VmMyVlFjbVZzYjJGa1pXUkVZWFJoWDBGc2JHOTNaV1F2TVE9PQwLEhNNYXN0ZXJGbGFrZUFuYWx5c2lzGAEM Please revert the culprit, or disable the test and find the appropriate owner. If the culprit above is wrong, please file a bug using this link: https://bugs.chromium.org/p/chromium/issues/entry?status=Unconfirmed&labels=Pri-1,Test-Findit-Wrong&components=Tools%3ETest%3EFindit%3EFlakiness&summary=%5BFindit%5D%20Flake%20Analyzer%20-%20Wrong%20result%20for%20MediaEngagementAutoplayBrowserTest.UsePreloadedData_Allowed/1&comment=Link%20to%20Analysis%3A%20https://findit-for-me.appspot.com/waterfall/flake?key=ag9zfmZpbmRpdC1mb3ItbWVy2QELEhdNYXN0ZXJGbGFrZUFuYWx5c2lzUm9vdCKiAWNocm9taXVtLmNocm9taXVtb3MvbGludXgtY2hyb21lb3MtZGJnLzc3ODUvc2luZ2xlX3Byb2Nlc3NfbWFzaF9icm93c2VyX3Rlc3RzL1RXVmthV0ZGYm1kaFoyVnRaVzUwUVhWMGIzQnNZWGxDY205M2MyVnlWR1Z6ZEM1VmMyVlFjbVZzYjJGa1pXUkVZWFJoWDBGc2JHOTNaV1F2TVE9PQwLEhNNYXN0ZXJGbGFrZUFuYWx5c2lzGAEM
,
Sep 13
I don't think the culprit identified is actually the cause of the flakiness. lethalantidote@: Could you PTAL and confirm?
,
Sep 14
Example failure: [1:1:0912/175026.597432: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. #0 0x7f5df4ba3a5d base::debug::StackTrace::StackTrace() #1 0x7f5df48b560c base::debug::StackTrace::StackTrace() #2 0x7f5df491f61d logging::LogMessage::~LogMessage() #3 0x7f5df4afcbda base::trace_event::MemoryDumpManager::UnregisterDumpProviderInternal() #4 0x7f5df4afc16f base::trace_event::MemoryDumpManager::UnregisterDumpProvider() #5 0x7f5dec274149 ws::ContextProviderCommandBuffer::~ContextProviderCommandBuffer() #6 0x7f5dec274af9 ws::ContextProviderCommandBuffer::~ContextProviderCommandBuffer() #7 0x7f5dec27c89b base::RefCountedThreadSafe<>::DeleteInternal<>() #8 0x7f5dec27c865 base::DefaultRefCountedThreadSafeTraits<>::Destruct() #9 0x7f5dec27bf6c base::RefCountedThreadSafe<>::Release() #10 0x7f5dec274dd9 ws::ContextProviderCommandBuffer::Release()
,
Sep 14
The comment above the DCHECK says
// 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.
I can't tell from the stack trace where this dump provider is. +primiano who added that DCHECK :)
,
Sep 14
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cd5317e7c3e26c1eab245f06643a0098ea6e4bdc commit cd5317e7c3e26c1eab245f06643a0098ea6e4bdc Author: Darren Shen <shend@chromium.org> Date: Fri Sep 14 04:16:06 2018 [sheriff] Disable flaky MediaEngagementAutoplayBrowserTest test. Timing out from crashing on Linux. TBR=beccahughes@chromium.org Bug: 883706 Change-Id: I4c618b6c4ad88a895ba53cd177106487fec8eba7 Reviewed-on: https://chromium-review.googlesource.com/1226475 Commit-Queue: Darren Shen <shend@chromium.org> Reviewed-by: Darren Shen <shend@chromium.org> Cr-Commit-Position: refs/heads/master@{#591287} [modify] https://crrev.com/cd5317e7c3e26c1eab245f06643a0098ea6e4bdc/chrome/browser/media/media_engagement_autoplay_browsertest.cc
,
Sep 14
that's some threading issue with ws::ContextProviderCommandBuffer, which calls unregister on a different task runner than the one passed here: https://cs.chromium.org/chromium/src/services/ws/public/cpp/gpu/context_provider_command_buffer.cc?sq=package:chromium&g=0&l=89 +sadrul to route this bug
,
Sep 17
,
Sep 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/47a3f38c37bc545b01c1f8eb90322ff057320fac commit 47a3f38c37bc545b01c1f8eb90322ff057320fac Author: James Cook <jamescook@chromium.org> Date: Thu Sep 20 19:21:11 2018 Re-enable MediaEngagementAutoplayBrowserTest.UsePreloadedData_Allowed It was disabled on all Linux platforms due to failures on Chrome OS in SingleProcessMash browser_tests. Instead, disable all MediaEngagement browser_tests via filter file for SingleProcessMash. There's a fix in-flight for renderer embedding in this mode, so I expect to re-enable them shortly. Bug: 884589 , 883706 , 881574 Change-Id: If6257ea160c7ba83c9bb322941001ce5ab1cc1b7 Reviewed-on: https://chromium-review.googlesource.com/1236836 Reviewed-by: Becca Hughes <beccahughes@chromium.org> Commit-Queue: James Cook <jamescook@chromium.org> Cr-Commit-Position: refs/heads/master@{#592897} [modify] https://crrev.com/47a3f38c37bc545b01c1f8eb90322ff057320fac/chrome/browser/media/media_engagement_autoplay_browsertest.cc [modify] https://crrev.com/47a3f38c37bc545b01c1f8eb90322ff057320fac/testing/buildbot/filters/chromeos.single_process_mash.browser_tests.filter |
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Sep 13