New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 860719
Owner:
Closed: Dec 27
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: ----



Sign in to add a comment
link

Issue 909043: headless_browsertests failing on chromium.win/Win10 Tests x64 (dbg)

Reported by sheriff-...@appspot.gserviceaccount.com, Nov 28 Project Member

Issue description

Filed by sheriff-o-matic@appspot.gserviceaccount.com on behalf of nednguyen@google.com

headless_browsertests failing on chromium.win/Win10 Tests x64 (dbg)

Builders failed on: 
- Win10 Tests x64 (dbg): 
  https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20Tests%20x64%20%28dbg%29
 

Comment 1 by nedngu...@google.com, Nov 28

Labels: -Pri-2 Pri-1
Owner: skyos...@chromium.org
Sammi: can you look into this or help triaging?

Comment 2 by skyostil@google.com, Nov 28

Cc: skyos...@chromium.org
Components: Internals>Headless
Owner: caseq@chromium.org
Looks like the renderer process is crashing in most (all?) tests:

../../headless/test/headless_browser_test.cc(266): error: Failed

Abnormal renderer termination

Stack trace:

Backtrace:

	StackTraceGetter::CurrentStackTrace [0x00007FF6A84F29F0+80]
	testing::internal::UnitTestImpl::CurrentOsStackTraceExceptTop [0x00007FF6A8509E3A+90]
	testing::internal::AssertHelper::operator= [0x00007FF6A850991A+90]
	headless::HeadlessAsyncDevTooledBrowserTest::RenderProcessExited [0x00007FF6A7F9F8C0+192]
	headless::HeadlessWebContentsImpl::RenderProcessExited [0x00007FFC8900633E+414]
	content::RenderProcessHostImpl::ProcessDied [0x00007FFC7D649474+1236]
	content::RenderProcessHostImpl::OnChannelError [0x00007FFC7D64B2F3+179]
	IPC::ChannelProxy::Context::OnDispatchError [0x00007FFC92A3C47D+45]

The log doesn't appear to contain the crash reason :\ However the latest runs on the bots are green now.

Comment 4 by xidac...@chromium.org, Dec 3

Labels: -Sheriff-Chromium

Comment 5 by fhorschig@chromium.org, Dec 12

Still flaky as of today. The rate of flakiness is quite high:
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=headless_browsertests&tests=Headless

Could someone please take a look?

(With all the experimental tests failing every single run on this bot, additional flakies like these distract a lot from other severe problems)

Comment 6 by mstensho@chromium.org, Dec 14

Merge this into bug 876224?

Comment 7 by hongchan@chromium.org, Dec 14

Status: Assigned (was: Available)
I am not sure why this still shows up on SoM even after the sheriff label is gone.

Comment 8 by bugdroid1@chromium.org, Dec 15

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7e42384992ccc9874365ba5f28ae389d527d1401

commit 7e42384992ccc9874365ba5f28ae389d527d1401
Author: Andrey Kosyakov <caseq@chromium.org>
Date: Sat Dec 15 02:50:23 2018

Fix a race in headless virtual time & compositor tests

A lack of explicit start time for frame caused real time clock to
be used for frame start, which may cause next frame to be dropped
if its (virtual) timestamp is earlier.

Bug:  909043 ,  843734 
Change-Id: I4a909be2e1e4f69f0834a87ffdb3d402c450adfc
Reviewed-on: https://chromium-review.googlesource.com/c/1379181
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616925}
[modify] https://crrev.com/7e42384992ccc9874365ba5f28ae389d527d1401/headless/test/data/protocol/emulation/compositor-image-animation-test.js
[modify] https://crrev.com/7e42384992ccc9874365ba5f28ae389d527d1401/headless/test/data/protocol/helpers/virtual-time-controller.js

Comment 9 by nedngu...@google.com, Dec 15

Cc: -nedngu...@google.com

Comment 10 by caseq@chromium.org, Dec 27

Mergedinto: 860719
Status: Duplicate (was: Assigned)

Sign in to add a comment