New issue
Advanced search Search tips

Issue 658304 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 2
Type: Bug



Sign in to add a comment

Layout Test fast/forms/select/input-select-after-resize.html is flaky

Project Member Reported by joh...@chromium.org, Oct 21 2016

Issue description

The following layout test flakily crashes and times out on Win, Linux:
fast/forms/select/input-select-after-resize.html

See https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Fforms%2Fselect%2Finput-select-after-resize.html

Sometimes it turns the build red despite automatic retries:
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win7%20(dbg)/builds/7722

Stack trace for crash (not sure why timeouts happen):

02:24:51.797 22989 worker/6 fast/forms/select/input-select-after-resize.html crashed, (stderr lines):
02:24:51.797 22989   [4:4:1021/022451:3240940356:FATAL:layouttest_support.cc(311)] Check failed: false. did not swap for reason 0
02:24:51.797 22989   #0 0x7f925a6569de base::debug::StackTrace::StackTrace()
02:24:51.797 22989   #1 0x7f925a6c5d0f logging::LogMessage::~LogMessage()
02:24:51.797 22989   #2 0x000000903925 content::(anonymous namespace)::CopyRequestSwapPromise::DidNotSwap()
02:24:51.797 22989   #3 0x7f925715e888 cc::LayerTreeImpl::BreakSwapPromises()
02:24:51.797 22989   #4 0x7f92571ef43a cc::SingleThreadProxy::CompositeImmediately()
02:24:51.797 22989   #5 0x7f9257157c77 cc::LayerTreeHostInProcess::Composite()
02:24:51.797 22989   #6 0x7f925d00c1c5 content::RenderWidgetCompositor::SynchronouslyComposite()
02:24:51.797 22989   #7 0x7f925b50b8ee _ZN4base8internal13FunctorTraitsIMN7content15ChildThreadImplEFvvEvE6InvokeIRKNS_7WeakPtrIS3_EEJEEEvS5_OT_DpOT0_
02:24:51.797 22989   #8 0x7f925d01035a _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN7content22RenderWidgetCompositorEFvvERKNS_7WeakPtrIS5_EEJEEEvOT_OT0_DpOT1_
02:24:51.797 22989   #9 0x7f925d0102e2 _ZN4base8internal7InvokerINS0_9BindStateIMN7content22RenderWidgetCompositorEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE7RunImplIRKS6_RKSt5tupleIJS8_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE
02:24:51.797 22989   #10 0x7f925d01022c _ZN4base8internal7InvokerINS0_9BindStateIMN7content22RenderWidgetCompositorEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE3RunEPNS0_13BindStateBaseE
02:24:51.797 22989   #11 0x7f925a65c8c1 _ZNO4base8internal8RunMixinINS_8CallbackIFvvELNS0_8CopyModeE0ELNS0_10RepeatModeE0EEEE3RunEv
02:24:51.797 22989   #12 0x7f925a65c2c9 base::debug::TaskAnnotator::RunTask()
02:24:51.797 22989   #13 0x7f92552ce2a1 blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue()
02:24:51.797 22989   #14 0x7f92552cbc52 blink::scheduler::TaskQueueManager::DoWork()
02:24:51.797 22989   #15 0x7f92552d4704 _ZN4base8internal13FunctorTraitsIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEvE6InvokeIRKNS_7WeakPtrIS4_EEJRKS5_RKbEEEvS7_OT_DpOT0_
02:24:51.797 22989   #16 0x7f92552d45b4 _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbERKNS_7WeakPtrIS6_EEJRKS7_RKbEEEvOT_OT0_DpOT1_
02:24:51.797 22989   #17 0x7f92552d4514 _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEJNS_7WeakPtrIS5_EES6_bEEEFvvEE7RunImplIRKS8_RKSt5tupleIJSA_S6_bEEJLm0ELm1ELm2EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE
02:24:51.797 22989   #18 0x7f92552d43ec _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEJNS_7WeakPtrIS5_EES6_bEEEFvvEE3RunEPNS0_13BindStateBaseE
02:24:51.798 22989   #19 0x7f925a65c8c1 _ZNO4base8internal8RunMixinINS_8CallbackIFvvELNS0_8CopyModeE0ELNS0_10RepeatModeE0EEEE3RunEv
02:24:51.798 22989   #20 0x7f925a65c2c9 base::debug::TaskAnnotator::RunTask()
02:24:51.798 22989   #21 0x7f925a6ee64a base::MessageLoop::RunTask()
02:24:51.798 22989   #22 0x7f925a6ee8d4 base::MessageLoop::DeferOrRunPendingTask()
02:24:51.798 22989   #23 0x7f925a6eebbe base::MessageLoop::DoWork()
02:24:51.798 22989   #24 0x7f925a706493 base::MessagePumpDefault::Run()
02:24:51.798 22989   #25 0x7f925a6ee1ca base::MessageLoop::RunHandler()
02:24:51.798 22989   #26 0x7f925a7948c4 base::RunLoop::Run()
02:24:51.798 22989   #27 0x7f925d1ee28c content::RendererMain()
02:24:51.798 22989   #28 0x7f925d5adf7e content::RunZygote()
02:24:51.798 22989   #29 0x7f925d5ae390 content::RunNamedProcessTypeMain()
02:24:51.798 22989   #30 0x7f925d5b07c2 content::ContentMainRunnerImpl::Run()
02:24:51.798 22989   #31 0x7f925d5ad622 content::ContentMain()
02:24:51.798 22989   #32 0x000000486cf9 main
02:24:51.798 22989   #33 0x7f924db1276d __libc_start_main
02:24:51.798 22989   #34 0x000000486be5 <unknown>
 
Project Member

Comment 1 by bugdroid1@chromium.org, Oct 21 2016

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

commit 0b9432e95072e3b5366b0f28c67743743847c358
Author: johnme <johnme@chromium.org>
Date: Fri Oct 21 17:24:45 2016

Mark fast/forms/select/input-select-after-resize.html flaky

BUG=658304
TBR=bokan@chromium.org
NOTRY=true
NOTREECHECKS=true

Review-Url: https://chromiumcodereview.appspot.com/2442803002
Cr-Commit-Position: refs/heads/master@{#426826}

[modify] https://crrev.com/0b9432e95072e3b5366b0f28c67743743847c358/third_party/WebKit/LayoutTests/TestExpectations

Comment 2 by tkent@chromium.org, Oct 22 2016

Components: -Blink>Forms Internals>Compositing

Comment 3 by enne@chromium.org, Nov 9 2016

Cc: danakj@chromium.org
bokan: ping.  Are you looking into this?

Comment 4 by bokan@chromium.org, Nov 9 2016

Labels: Hotlist-Input-Dev
It's on my plate but I've been quite busy lately. I'll take a look either next week or find someone to take a look.
Reason 0 is SWAP_FAILS which is happening https://cs.chromium.org/chromium/src/cc/trees/single_thread_proxy.cc?rcl=1478693914&l=493 because STL::DoComposite is not actually producing a frame.

It can happen because CanDraw() is false or LTHI is not visible: https://cs.chromium.org/chromium/src/cc/trees/single_thread_proxy.cc?rcl=1478693914&l=534

I can't find another reason why. bokan would you please bisect or debug further?

Comment 6 by danakj@chromium.org, Dec 16 2016

> It's on my plate but I've been quite busy lately. I'll take a look either next week or find someone to take a look.

We're not treating this like P1, is it wrong?

Comment 7 by bokan@chromium.org, Dec 16 2016

Labels: -Pri-1 Pri-2
Do you suspect it's linked to some other issues or is it just this test? If it's just this test then I don't think it's P1, it's relatively recently added and testing a fairly obscure bug. I've been meaning to take a look but I've got a bunch of release blockers that are higher priority.

Comment 8 by danakj@chromium.org, Dec 16 2016

Usually test failures indicate a bug, but I dont know about this test to be sure. Flaky tests are a huge problem tho cuz they must be disabled and then we lose the coverage they were meant to provide which erodes our product quality. </soapbox> :)

Comment 9 by bokan@chromium.org, Dec 16 2016

Yup, fully appreciate the importance of tests and I'm not sweeping this under the rug :).

In this case, the test is testing inter process behavior so the timing of resize IPCs getting ACK'd is very likely responsible for flakiness. I'll likely have to rewrite it, layout test is probably the wrong place for this.
Components: -Blink>LayoutTests

Sign in to add a comment