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

Issue 751253 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Fuchsia
Pri: 2
Type: Bug



Sign in to add a comment

DCHECK log output + stack isn't reported if number of jobs is two or more

Project Member Reported by w...@chromium.org, Aug 1 2017

Issue description

If you run a set of tests that includes a crash due to CHECK/DCHECK, then we don't seem to report the crash stack or DCHECK message - it looks like we're losing the stdio output.

Running an individual test locally does report the crash stack, suggesting that this may be specific to the TestLauncher's stdio redirection for the n>1 job case?
 

Comment 1 by w...@chromium.org, Aug 1 2017

Summary: DCHECK log output + stack isn't reported if number of jobs is two or more (was: CHECK log output isn't being reported in bot stdio)
Yes, I've noticed this too and worked around it with --gtest_filter=* (or similarly --test-launcher-jobs=1 I think would work).

I didn't investigate whether it was general test launcher behaviour, or perhaps I wrote a bug in base/test or base/process as far as getting output redirected.

Comment 3 by w...@chromium.org, Aug 1 2017

Cc: jam...@chromium.org
Owner: kmarshall@chromium.org
Status: Assigned (was: Untriaged)
Seems that we tend to get one line of output from the sub-process, and then nothing more.

Sub-process output is redirected to a temporary file which the TestLauncher pulls the contents from, suggesting that the crashing sub-process may not be flushing correctly.

Comment 4 by w...@chromium.org, Aug 1 2017

Output being logged is logged by base/logging, and is essentially fwrite(stderr, ...); fflush(stderr).

Output is then read back by TestLauncher using ReadFileToString(), which jsut open(..., "rb")s the file and fread()s its entire contents.
Owner: w...@chromium.org

Comment 6 by w...@chromium.org, Aug 1 2017

Labels: -Pri-3 M-62 Pri-2
Status: Started (was: Assigned)
We're missing stderr from failing tests because the redirected-output file is missing all the stdout lines, preventing GetTestOutputSnippet from finding the individual test's output lines in the batches output.

This suggests a fault in the FD remapping of the Fuchsia LaunchProcess implementation, or the underlying launchpad APIs.

Comment 7 by w...@chromium.org, Aug 2 2017

This looks like an edge-case (one parent FD mapped to two different child FDs) that the mxio __libc_extensions_init doesn't handle quite correctly - filed https://fuchsia.atlassian.net/browse/MG-985.
Project Member

Comment 8 by bugdroid1@chromium.org, Aug 4 2017

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

commit e5e63e607292ffc1bc65e35ee52f2612d462ee27
Author: Wez <wez@chromium.org>
Date: Fri Aug 04 18:48:53 2017

Open TestLauncher batch output files with O_APPEND

This works around a bug in LaunchProcess() under Fuchsia, which results
in a single seekable file FD mapped to multiple FDs in a target process
ending up with independent seek positions into the file, and writes to
the two FDs therefore trampling one another.

Bug:  751253 
Change-Id: I9d8538744ad7048b93c2ebaf49323b1d399e9510
Reviewed-on: https://chromium-review.googlesource.com/598696
Commit-Queue: Wez <wez@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#492088}
[modify] https://crrev.com/e5e63e607292ffc1bc65e35ee52f2612d462ee27/base/test/launcher/test_launcher.cc

Comment 9 by w...@chromium.org, Aug 4 2017

Status: Fixed (was: Started)

Sign in to add a comment