New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 626203 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug-Regression



Sign in to add a comment

telemetry.internal.browser.browser_unittest.BrowserTest.testCloseReferencedTab failing with FATAL:resource_provider.cc(1189): Check failed: false. Image not valid

Project Member Reported by kbr@chromium.org, Jul 7 2016

Issue description

Telemetry rolls started failing earlier today (see https://github.com/catapult-project/catapult/issues/2455 ) because telemetry.internal.browser.browser_unittest.BrowserTest.testCloseReferencedTab started flakily failing on Linux. Here is just one example failing build:

https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/257759

Here's the stack trace:

  *************** BROWSER STANDARD OUTPUT ***************
  [1:1:0706/082836:ERROR:memory_mapped_file.cc(52)] Couldn't open /tmp/isolated_runE_2mpZ/out/Release/chrome_200_percent.pak
  [1:1:0706/082836:ERROR:data_pack.cc(80)] Failed to mmap datapack
  Xlib:  extension "RANDR" missing on display ":9".
  [13744:13744:0706/082836:ERROR:memory_mapped_file.cc(52)] Couldn't open /tmp/isolated_runE_2mpZ/out/Release/chrome_200_percent.pak
  [13744:13744:0706/082836:ERROR:data_pack.cc(80)] Failed to mmap datapack
  Xlib:  extension "RANDR" missing on display ":9".
  [13782:13782:0706/082836:ERROR:sandbox_linux.cc(343)] InitializeSandbox() called with multiple threads in process gpu-process. 
  [13744:13765:0706/082836:ERROR:browser_gpu_channel_host_factory.cc(131)] Failed to create channel.
  [13744:13744:0706/082837:FATAL:resource_provider.cc(1189)] Check failed: false. Image not valid
  #0 0x7f66fd26e1de base::debug::StackTrace::StackTrace()
  #1 0x7f66fd28601b logging::LogMessage::~LogMessage()
  #2 0x7f66fdf6c160 cc::ResourceProvider::ScopedReadLockSkImage::ScopedReadLockSkImage()
  #3 0x7f66fe0172d4 cc::SoftwareRenderer::DrawTileQuad()
  #4 0x7f66fe015a9b cc::SoftwareRenderer::DoDrawQuad()
  #5 0x7f66fe0530f5 cc::DirectRenderer::DrawRenderPass()
  #6 0x7f66fe05240c cc::DirectRenderer::DrawRenderPassAndExecuteCopyRequests()
  #7 0x7f66fe0521ac cc::DirectRenderer::DrawFrame()
  #8 0x7f66fe32ca72 cc::Display::DrawAndSwap()
  #9 0x7f66fe32e6d9 cc::DisplayScheduler::DrawAndSwap()
  #10 0x7f66fe32da46 cc::DisplayScheduler::OnBeginFrameDeadline()
  #11 0x7f66fd2b0a51 _ZN4base8internal7InvokerINS0_9BindStateIMNS_7RunLoopEFvvEJNS_7WeakPtrIS3_EEEEEFvvEE3RunEPNS0_13BindStateBaseE
  #12 0x7f66fa20e941 _ZN4base8internal7InvokerINS0_9BindStateIMN8autofill15AutofillManagerEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE3RunEPNS0_13BindStateBaseE
  #13 0x7f66fd2fdfc9 base::debug::TaskAnnotator::RunTask()
  #14 0x7f66fd28d745 base::MessageLoop::RunTask()
  #15 0x7f66fd28da58 base::MessageLoop::DeferOrRunPendingTask()
  #16 0x7f66fd28dd7b base::MessageLoop::DoWork()
  #17 0x7f66fd28fcda base::(anonymous namespace)::WorkSourceDispatch()
  #18 0x7f66f827dd13 g_main_context_dispatch
  #19 0x7f66f827e060 <unknown>
  #20 0x7f66f827e124 g_main_context_iteration
  #21 0x7f66fd28faa6 base::MessagePumpGlib::Run()
  #22 0x7f66fd28d241 base::MessageLoop::RunHandler()
  #23 0x7f66fd2b06c0 base::RunLoop::Run()
  #24 0x7f66fd152b7a ChromeBrowserMainParts::MainMessageLoopRun()
  #25 0x7f66fa969cd9 content::BrowserMainLoop::RunMainMessageLoopParts()
  #26 0x7f66fa96cfe8 content::BrowserMainRunnerImpl::Run()
  #27 0x7f66fa96586c content::BrowserMain()
  #28 0x7f66fceb48cb content::RunNamedProcessTypeMain()
  #29 0x7f66fceb5343 content::ContentMainRunnerImpl::Run()
  #30 0x7f66fceb3c10 content::ContentMain()
  #31 0x7f66fa1ecf3b ChromeMain
  #32 0x7f66f32547ed __libc_start_main
  #33 0x7f66fa1ece11 <unknown>

This is a recent flaky regression and needs to be diagnosed right away as it forced disabling of an important test. Who can triage it?

 

Comment 1 by robe...@opera.com, Jul 7 2016

Cc: robe...@opera.com
Just an FYI, we're also seeing this. I've looked a little bit at the problem, and what seems to be happening is that the HostSharedBitmapManagerClient is being destroyed when the renderer is killed (since it's owned by RenderMessageFilter), causing it to clear out all the bitmaps available in HostSharedBitmapManager by calling manager_->ChildDeleteSharedBitmap(..). After that, a Resource tries to fetch one of the removed bitmaps, causing the NONREACHED() to be reached.

Not quite sure what the expected behavior is though.

Comment 2 by enne@chromium.org, Jul 7 2016

Owner: enne@chromium.org
Status: Assigned (was: Untriaged)
I'll take a look at this, as it's my change.  This used to just be a DCHECK and now is a NOTREACHED, which is why it's crashing.

Comment 3 by enne@chromium.org, Jul 7 2016

robertn: Can I ask what steps you used to repro this? I've been unable to make it happen locally.
Project Member

Comment 4 by bugdroid1@chromium.org, Jul 7 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/011f68cd2fa0d9fff7fd9808043d6a7fae6e478c

commit 011f68cd2fa0d9fff7fd9808043d6a7fae6e478c
Author: enne <enne@chromium.org>
Date: Thu Jul 07 22:16:17 2016

cc: Remove DCHECK for invalid image

This appears to happen sometimes due to render process shutdown racing
with drawing a frame using software resources from that renderer.
Previously this wouldn't DCHECK at all and would just early out.

BUG= 626203 , chromedriver:1418 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2132723002
Cr-Commit-Position: refs/heads/master@{#404251}

[modify] https://crrev.com/011f68cd2fa0d9fff7fd9808043d6a7fae6e478c/cc/resources/resource_provider.cc

Comment 5 by robe...@opera.com, Jul 8 2016

enne: It was happening when shutting down after a test case that registered a unload event handler, so I'm guessing it was somehow related to that, but I haven't confirmed that yet (and not every time - rougly 1 out of 5 times).

Comment 6 by enne@chromium.org, Jul 11 2016

Status: Fixed (was: Assigned)
Ok, thanks.  I was able to repro by running with --disable-gpu, going to about://version, and then just mashing alt-left arrow and alt-right arrow to go back and forth between pages for a few seconds.

I'm not sure this race can be easily fixed without a lot of extra complication, so am just going to continue to work around it for now.

Comment 7 by enne@chromium.org, Jul 28 2016

Labels: Merge-Request-53

Comment 8 by enne@chromium.org, Jul 28 2016

Cc: samu...@chromium.org
 Issue 632175  has been merged into this issue.

Comment 9 by dimu@chromium.org, Jul 28 2016

Labels: -Merge-Request-53 Merge-Approved-53 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M53 (branch: 2785)
Project Member

Comment 10 by bugdroid1@chromium.org, Jul 28 2016

Labels: -merge-approved-53 merge-merged-2785
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/26d84ddd5e900ab6f508b2fbf72a1caa9b1f8a51

commit 26d84ddd5e900ab6f508b2fbf72a1caa9b1f8a51
Author: Adrienne Walker <enne@chromium.org>
Date: Thu Jul 28 19:01:54 2016

cc: Remove DCHECK for invalid image

This appears to happen sometimes due to render process shutdown racing
with drawing a frame using software resources from that renderer.
Previously this wouldn't DCHECK at all and would just early out.

BUG= 626203 , chromedriver:1418 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2132723002
Cr-Commit-Position: refs/heads/master@{#404251}
(cherry picked from commit 011f68cd2fa0d9fff7fd9808043d6a7fae6e478c)

Review URL: https://codereview.chromium.org/2190063002 .

Cr-Commit-Position: refs/branch-heads/2785@{#393}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/26d84ddd5e900ab6f508b2fbf72a1caa9b1f8a51/cc/resources/resource_provider.cc

Sign in to add a comment