New issue
Advanced search Search tips

Issue 715964 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

"FileDownloaderTest.DontOverwrite" is flaky

Project Member Reported by chromium...@appspot.gserviceaccount.com, Apr 27 2017

Issue description

"FileDownloaderTest.DontOverwrite" is flaky.

This issue was created automatically by the chromium-try-flakes app. Please find the right owner to fix the respective test/step and assign this issue to them. If the step/test is infrastructure-related, please add Infra-Troopers label and change issue status to Untriaged. When done, please remove the issue from Sheriff Bug Queue by removing the Sheriff-Chromium label.

We have detected 5 recent flakes. List of all flakes can be found at https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyKwsSBUZsYWtlIiBGaWxlRG93bmxvYWRlclRlc3QuRG9udE92ZXJ3cml0ZQw.

Flaky tests should be disabled within 30 minutes unless culprit CL is found and reverted. Please see more details here: https://sites.google.com/a/chromium.org/dev/developers/tree-sheriffs/sheriffing-bug-queues#triaging-auto-filed-flakiness-bugs
 
Error log:
=== START ===
[ RUN      ] FileDownloaderTest.DontOverwrite
[4038:4038:0426/062557.811105:4681840485:FATAL:post_task.cc(88)] Check failed: TaskScheduler::GetInstance(). Ref. Prerequisite section of post_task.h
#0 0x00000418dff7 base::debug::StackTrace::StackTrace()
#1 0x0000041a72fd logging::LogMessage::~LogMessage()
#2 0x0000041f06d4 base::CreateTaskRunnerWithTraits()
#3 0x000004497e67 FileDownloader::OnURLFetchComplete()
#4 0x000003aad50e net::FakeURLFetcher::RunDelegate()
#5 0x000000910087 _ZN4base8internal7InvokerINS0_9BindStateIMN12_GLOBAL__N_115FakeMediaRouterEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE7RunOnceEPNS0_13BindStateBaseE
#6 0x000000652d71 _ZNO4base8CallbackIFvvELNS_8internal8CopyModeE0ELNS2_10RepeatModeE0EE3RunEv
#7 0x000004241e93 base::debug::TaskAnnotator::RunTask()
#8 0x0000041aeafd base::MessageLoop::RunTask()
#9 0x0000041aeda8 base::MessageLoop::DeferOrRunPendingTask()
#10 0x0000041af246 base::MessageLoop::DoWork()
#11 0x0000041b0b8b base::MessagePumpDefault::Run()
#12 0x0000041ae85e base::MessageLoop::RunHandler()
#13 0x0000041d631c base::RunLoop::Run()
#14 0x00000097ed3a FileDownloaderTest::Download()
#15 0x00000097f970 FileDownloaderTest_DontOverwrite_Test::TestBody()
#16 0x000003ee5c26 testing::Test::Run()
#17 0x000003ee6700 testing::TestInfo::Run()
#18 0x000003ee6c27 testing::TestCase::Run()
#19 0x000003eedc67 testing::internal::UnitTestImpl::RunAllTests()
#20 0x000003eed8e7 testing::UnitTest::Run()
#21 0x0000036ef611 base::TestSuite::Run()
#22 0x0000036f1390 base::(anonymous namespace)::LaunchUnitTestsInternal()
#23 0x0000036f1204 base::LaunchUnitTests()
#24 0x0000036e8cda main
#25 0x7fee11884f45 __libc_start_main
#26 0x000000649f5d <unknown>
=== END ===

Suspect https://codereview.chromium.org/2835303002
(the last one to touch file_downloader_unittest.cc and related to TaskScheduler).
Cc: fdoray@chromium.org
The CL from the comment above touched OnURLFetchComplete in FileDownloader, basically adding base::CreateTaskRunnerWithTraits. Trying to revert.
Project Member

Comment 4 by bugdroid1@chromium.org, Apr 27 2017

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

commit dfd5b6f49e5382da44646018e2471a3e9f15f96f
Author: vitaliii <vitaliii@chromium.org>
Date: Thu Apr 27 11:33:18 2017

Revert of Use TaskScheduler instead of blocking pool in file_downloader.cc. (patchset #2 id:20001 of https://codereview.chromium.org/2835303002/ )

Reason for revert:
"FileDownloaderTest.DontOverwrite" is flaky.
 crbug.com/715964 

Original issue's description:
> Use TaskScheduler instead of blocking pool in file_downloader.cc.
>
> The blocking pool is being deprecated in favor of TaskScheduler.
>
> BUG= 667892 
> R=asanka@chromium.org
>
> Review-Url: https://codereview.chromium.org/2835303002
> Cr-Commit-Position: refs/heads/master@{#467397}
> Committed: https://chromium.googlesource.com/chromium/src/+/4f0ba69f0ae32dc9e48fc021852585abb0df35b5

TBR=asanka@chromium.org,fdoray@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 667892 , 715964 

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

[modify] https://crrev.com/dfd5b6f49e5382da44646018e2471a3e9f15f96f/chrome/browser/net/file_downloader.cc
[modify] https://crrev.com/dfd5b6f49e5382da44646018e2471a3e9f15f96f/chrome/browser/net/file_downloader_unittest.cc

Status: Fixed (was: Untriaged)

Comment 6 by fdoray@chromium.org, Apr 27 2017

Components: Infra>Flakiness
Owner: serg...@chromium.org
Status: Untriaged (was: Fixed)
It looks like failures when running a CQ dry run on the first patch set of my CL were reported as flakes. I fixed the failures in the second patch set. I landed the second patch set. And my CL was reverted because of flakes in the first patch set.

E.g.
https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_ng/builds/439029
is linked from
https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyKwsSBUZsYWtlIiBGaWxlRG93bmxvYWRlclRlc3QuRG9udE92ZXJ3cml0ZQw
and from
https://codereview.chromium.org/2835303002/#ps1

Also, the same linux_chromium_rel_ng test is linked 3 times from https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/439401
Labels: -Sheriff-Chromium
I am sorry for missing that the failures were in the first patch-set and happened all at the same time.
Components: -Infra>Flakiness
Owner: ----
Status: WontFix (was: Untriaged)
Normally chromium-try-flakes will file bugs for flaky tests that have flaked at least 3 times in the last 24 hours. It seems that in this particular case all these flakes have happened on the 1st patchset of your CL, but that patchset did not land. Normally that does not happen since a flake is detected only when there is a passing and a failing build and patchsets which have green builds end up in the tree. Looks like here you've used a dry run first, which passed and then a full run, which failed. This is a corner-case that chromium-try-flakes does not handle yet, sorry for the false positive.

I think the solution here would be to only file a bug if a flake has happened on at least 2 different patchsets. I am going to close this bug as WontFix and this suggestion to issue 583446.

Sign in to add a comment