Issue 803189  has been merged into this issue.

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

commit d562f566350e338ddfe3bb615d5aa74fb4be1c50
Author: Sorin Jianu <sorin@chromium.org>
Date: Thu Jan 18 00:27:17 2018

Disable TerminateOnServiceQuit on Chromium OS and ASAN

The test has been quite flaky recently.
TBR=rockot

Bug:  803188 
Change-Id: Id69d5ef60b6c759f2465cd1e9a4b542750a230f9
Reviewed-on: https://chromium-review.googlesource.com/871983
Reviewed-by: Sorin Jianu <sorin@chromium.org>
Commit-Queue: Sorin Jianu <sorin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529975}
[modify] https://crrev.com/d562f566350e338ddfe3bb615d5aa74fb4be1c50/content/browser/service_manager/service_manager_context_browsertest.cc

I think the regression range is unlikely to matter here and the appearance of increased flake is probably coincidental.

I am totally unable to repro locally, but that may just be to timing or subtle differences between the bot's and my libc. After some investigation and manual symbolization of the bot's unsymbolized stacks (e.g. tail of the log at https://chromium-swarm.appspot.com/task?id=3b1e4119a4190d10&refresh=10&request_detail=true&show_raw=1), the is flaky crash seems to always come from a read() call within base::GetAppOutputInternal.

The code within looks just fine, but I notice that aforementioned function uses fork(), which means it's inherently unsafe to call in a multithreaded environment. If I can just make TerminateOnService quit (not MANUAL_TerminateOnServiceQuit) a single-threaded non-browsertest, that might be sufficient to avoid flake.

rockot, I just did the MANUAL_TerminateOnServiceQuit thing because it was similar to another test ContentBrowserTest.BrowserCrashCallStack. If there's a better way to do it, please feel free to change the test. Alternately, you can assign this to me and I can look at it later.

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

commit f8e92a3c40bd7c687b84655e0e6a470f01662466
Author: Ken Rockot <rockot@chromium.org>
Date: Fri Jan 19 01:24:09 2018

Re-enable ServiceManagerContextTest.TerminateOnServiceQuit

This was disabled on Chrome OS + ASAN due to flakiness.

I suspect the flakiness is caused by use of fork() in a
multithreaded environment, via base::GetAppOutputAndError.

This CL changes the offending test to not use the
ContentBrowserTest fixture and instead simply call
base::GetAppOutputAndError from a single-threaded unit
test. The manually launched browser test in the launched
subprocess remains unchanged.

Renames the browser test fixture to
ServiceManagerContentBrowserTest to disambiguate from the
new non-browser-test test case.

Bug:  803188 
Change-Id: I5d1be42cb35ccc6ec79ed1cbda83018291aecaa2

TBR=jam

Change-Id: I5d1be42cb35ccc6ec79ed1cbda83018291aecaa2
Reviewed-on: https://chromium-review.googlesource.com/875269
Commit-Queue: Ken Rockot <rockot@chromium.org>
Reviewed-by: James Cook <jamescook@chromium.org>
Cr-Commit-Position: refs/heads/master@{#530377}
[modify] https://crrev.com/f8e92a3c40bd7c687b84655e0e6a470f01662466/content/browser/service_manager/service_manager_context_browsertest.cc

Calling the odd stack trace as fixed. I'm not even sure this was anything but a timeout now, but I am sure that fork()+threads is bad, so I'll leave the timeout tracked on bug 803814.