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

Issue 678146 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug

Blocking:
issue 666356



Sign in to add a comment

Work around minikin logging to stdout in tests w/ RunInSubThread set

Project Member Reported by jbudorick@chromium.org, Jan 4 2017

Issue description

Tests running with RunInSubThread -- currently, just net_unittests, though several more suites will do so when https://codereview.chromium.org/2549363004 lands -- on L and M have a bunch of referenceTable log lines printed to their stdout, e.g.

I   37.671s run_tests_on_device(00f0146727efaa0a)  referenceTable GDEF length=808 1
I   37.671s run_tests_on_device(00f0146727efaa0a)  referenceTable GSUB length=11364 1
I   37.671s run_tests_on_device(00f0146727efaa0a)  referenceTable GPOS length=49128 1
I   37.671s run_tests_on_device(00f0146727efaa0a)  referenceTable head length=54 1

This races with the gtest stdout and can consequently cause parsing errors when running or listing tests.

This was tracked on the android side by https://code.google.com/p/android/issues/detail?id=167715 and appears to have been fixed starting in N.
 
Blocking: 666356
Labels: -Pri-2 Pri-1
(bumping priority to match blocked bug)
The code responsible for the referenceTable lines gets posted to the main thread after start() (and thus postStart()) returns. When running tests in the main thread, we currently post the test execution task to the main thread in postStart(), so we finish running tests before the referenceTable logic runs. When running tests in a subthread, we currently don't post anything to the main thread handler, so the referenceTable logic can run concurrently with test execution. I'm trying out a few different ideas to address this, starting with blocking the main thread handler on the subthread.
Blocking the main thread isn't viable. I've instead settled on an implementation that posts a task that posts a task that starts the tests. This should ensure that the system task runs before the subthread starts.
Project Member

Comment 4 by bugdroid1@chromium.org, Jan 4 2017

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

commit ff8298584409040003a088792394d4ea3101f8d4
Author: jbudorick <jbudorick@chromium.org>
Date: Wed Jan 04 20:53:10 2017

[Android] Fix subthread native test execution race condition.

On L and M, the system posts a task to the main thread after start() returns
that prints a few lines to stdout. Our existing subthread execution model
allowed the tests to run at the same time as this task, resulting in the
task's output interfering with the tests' output.

This change tweaks our subthread test launching logic to post a task to the
main thread that posts another task to the main thread that launches the test
subthread. This should ensure that the system task gets executed before we
start running tests.

BUG= 678146 

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

[modify] https://crrev.com/ff8298584409040003a088792394d4ea3101f8d4/testing/android/native_test/java/src/org/chromium/native_test/NativeTest.java

Status: Fixed (was: Started)

Sign in to add a comment