MojoTestState registers the content_package_services as a service of the  BackgroundServiceManager created to run the test case.

MojoTestConnector::ServiceProcessLauncherDelegateImpl::AdjustCommandLineArgumentsForTarget eventually handles a request to launch the content_package_service. This launch has a CommandLine of the following form:

--test-launcher-filter-file=testing/buildbot/filters/mash.browser_tests.filter --service-name=content_packaged_services --u=51ec3e58-c2ef-4380-b0d1-2e914243aab1 --mojo-platform-channel-handle=3 --service-pipe-token=44066EADB7595FF0AE512697690EF635

In RunMashBrowserTests, which is used to launch this child process, the lack of --run-in-mash leads to rejecting the mash path. Falling back on LaunchChromeTests. However the existence of the --service-pipe tells Aura that it is not running locally.

This child continues the test path, sees the --test-launcher-filter-file and begins to spin up the entire test suite again.

This leads to all the tests being ran an additional time. However they are in a weird mixed state, with Aura non-local, but Ash is local.

This is the cause of the following stack trace:
[3711:3711:0630/060854.689632:FATAL:ozone_platform.cc(69)] Check failed: instance_. OzonePlatform is not initialized
#0 0x0000037c1fdc base::debug::StackTrace::StackTrace()
#1 0x0000037dab81 logging::LogMessage::~LogMessage()
#2 0x000001ec7d42 ui::OzonePlatform::GetInstance()
#3 0x0000062a733e ash::ShellPortClassic::CreateNativeDisplayDelegate()
#4 0x0000062e24fc ash::Shell::Init()
#5 0x0000062e1fe9 ash::Shell::CreateInstance()
#6 0x00000679dbed AshInit::AshInit()
#7 0x00000659dd60 ChromeBrowserMainExtraPartsAsh::PreProfileInit()
#8 0x0000038f277a ChromeBrowserMainParts::PreProfileInit()
#9 0x0000038f37d0 ChromeBrowserMainPartsLinux::PreProfileInit()
#10 0x0000019749c3 chromeos::ChromeBrowserMainPartsChromeos::PreProfileInit()
#11 0x0000038f19fa ChromeBrowserMainParts::PreMainMessageLoopRunImpl()
#12 0x0000038f137d ChromeBrowserMainParts::PreMainMessageLoopRun()
#13 0x0000019745f0 chromeos::ChromeBrowserMainPartsChromeos::PreMainMessageLoopRun()
#14 0x000002371e41 content::BrowserMainLoop::PreMainMessageLoopRun()
#15 0x00000275e4b7 content::StartupTaskRunner::RunAllTasksNow()
#16 0x0000023702cf content::BrowserMainLoop::CreateStartupTasks()
#17 0x000002374722 content::BrowserMainRunnerImpl::Initialize()
#18 0x00000236d8e7 content::BrowserMain()
#19 0x00000376b35c content::ContentMainRunnerImpl::Run()
#20 0x00000566b1a4 service_manager::Main()
#21 0x00000376a1a4 content::ContentMain()
#22 0x000003e61812 content::BrowserTestBase::SetUp()
#23 0x0000038b0753 InProcessBrowserTest::SetUp()
#24 0x000001c75b41 testing::Test::Run()
#25 0x000001c76650 testing::TestInfo::Run()
#26 0x000001c76b87 testing::TestCase::Run()
#27 0x000001c7dd27 testing::internal::UnitTestImpl::RunAllTests()
#28 0x000001c7d9ab testing::UnitTest::Run()
#29 0x0000038c4b86 base::TestSuite::Run()
#30 0x0000037b4b83 ChromeTestSuiteRunner::RunTestSuite()
#31 0x000003e94c82 content::LaunchTests()
#32 0x0000037b27d3 main
#33 0x7faf41ae7f45 __libc_start_main
#34 0x00000062360e <unknown>

However this nested test suite does not affect the results of the original, so the tests keep passing.

Meanwhile, the actual test cases being ran have a different CommandLine from the one seen for content_package_services. Of the form:

./out/oxygen/browser_tests --gtest_also_run_disabled_tests --gtest_filter=ExperimentalAppWindowApiTest.SetIcon --is_test --mojo-platform-channel-handle=3 --mus-config=mash --run-in-mash --service-pipe-token=5B02DFB89A65AFDA48B530DEB59F366D --single_process --test-launcher-filter-file=testing/buildbot/filters/mash.browser_tests.filter --user-data-dir=/tmp/.org.chromium.Chromium.lWdjC3/dRjXgFg

This results in the individual test case being ran, in the correct non-local Ash and Aura config. It also doesn't cause a nested test state.

For now I plan to disable RunMashBrowserTests from nesting further test suite runs, by simply absorbing the launch of content_package_services. For the current filter set, this does not appear to cause any new failures.

Afterwards I'll hunt down what is attempting to connect to content_package_services, and then see about properly launching it.