For reference:
Good https://gist.github.com/sgraham/1a861f491bbe962fbea4135249f39ea3
Bad: https://gist.github.com/sgraham/bafdc0aff92204f8ec528467c55b59bd

Can you provide an example of what the problem is that this CL describes?

If you mean that we don't get output when a test fails under TestLauncher then that most likely means that O_APPEND propagation has regressed again - we rely on that to ensure that stdio and stderr don't trample one another in the child processes.

[(49fa9a034039...)|BISECTING] scottmg@around:/work/cr/src$ git bisect bad
49fa9a0340396393a00ba0e276717f877ff1eb2e is the first bad commit
commit 49fa9a0340396393a00ba0e276717f877ff1eb2e
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date:   Tue Sep 25 01:04:30 2018 +0000

    Roll Fuchsia SDK from f1d59a7ee9f4 to 98ba6c8440c2
    
    
    The AutoRoll server is located here: https://autoroll.skia.org/r/fuchsia-sdk-chromium-autoroll
    
    Documentation for the AutoRoller is here:
    https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
    
    If the roll is causing failures, please contact the current sheriff, who should
    be CC'd on the roll, and stop the roller if necessary.
    
    
    CQ_INCLUDE_TRYBOTS=luci.chromium.try:fuchsia_arm64_cast_audio;luci.chromium.try:fuchsia_x64_cast_audio
    TBR=cr-fuchsia+bot@chromium.org
    
    Change-Id: I2fb983c293be0f4290025e212139df64e9647791
    Reviewed-on: https://chromium-review.googlesource.com/1242057
    Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
    Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
    Cr-Commit-Position: refs/heads/master@{#593789}

:040000 040000 c8a381e9bee3c9fca68a371caa6970cfba922046 5c0b7eb33ef07879a77b48037072833a4657f784 M	build

The links are there in #c1. "Good" has output from our test binary, "Bad" has no output from our binary whatsoever.

Turns out this was because I was using e.g.

out/fuch/bin/run_base_unittests -d

But after syncing, I didn't reboot, so the kernel, etc. weren't updated to match the user space stuff that the test binaries were linked against.

So I could just remember to do that. Or I could add some sort of check to the runners.

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

commit 13100a642d1dca2dcec1be7f1b91b38ec445b02e
Author: Scott Graham <scottmg@chromium.org>
Date: Wed Sep 26 00:18:50 2018

fuchsia: Ensure target SDK matches when connecting to previous netboot

I was confused by some weird behaviour (see linked bug) when I forgot to
reboot my device after syncing a new SDK.

To detect this, stash SDK_ROOT/.hash as /data/.hash after successfully
netbooting, and if that doesn't match on a subsequent run then reboot
the target before continuing.

This is not quite correct, in that if you sync a new SDK and then run
(without building) it will be looking at the synced SDK's hash rather
than whatever the binary you're running is built against. But I don't
think we have a way to figure out what SDK a binary was built against,
so this seems low-cost/more-correct than what we had before.

Bug:  889215 
Change-Id: I578e9acf33beba17769acebe8f46f7216f93b596
Reviewed-on: https://chromium-review.googlesource.com/1244825
Reviewed-by: Kevin Marshall <kmarshall@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594155}
[modify] https://crrev.com/13100a642d1dca2dcec1be7f1b91b38ec445b02e/build/fuchsia/device_target.py