primiano@ Sorry to rope you into v2 of the bug ;)  but can you please provide an opinion on option C?

sky@ we discussed option C offline and after some further consideration I don't think there are actually any security problems. Once the process is sandboxed, the worst it can do is crash itself. i.e. there isn't still privileged code running anywhere in the process.

+thakis@, maybe he has some alternative idea here.
Context for thakis (this bug is quite hairy):
-----
I believe so far we never considered the use-case of base being linked in more than one linker unit which depends on each other. This is causing problem to these guys (TL;DR ODR violation of the allocator syms) when mojo_runner.exe dlopen()'s a .so, and both mojo_runner.exe and the .so statically link base and hence have the allocator symbols. Depending on how the code in the .so (or worse, its dependencies) reaches the allocator (via PLT jump, or via direct jumps) they end up in a split-heap situation (alloc in one heap, free in another).
rockot@ tried a combination of RTLD_DEEPBIND and adding more PLT trampolines, but that just shuffles the problem around without really solving it.
One of the core problems is that in chrome we have various paths to enter the allocator. It's not just malloc/free/new. There is base::UncheckedMalloc. And god knows whatever else calls directly tc_ functions.
Essentially the problem here seems that they don't want the allocator in *all* the linker units that link base, but they still need "base".
---

> For example, a third-party runtime dependency may call libc's getline() which internally calls malloc(); that malloc call will resolve to the mojo_runner's definition since mojo_runner also links against libc
Ahh got it. What you say makes sense. once mojo_runnner loads libc and calls something in it, the malloc PLT of libc will be bound against the mojo_runner's definition, because that't the root of the loader search chain. And when you use libc from the DSO libc is already loaded and DEEPBIND won't change anything there.
Again that's yet another argument that trying to have more than one allocator definition just doesn't work, despite our attempts to do clever things with DEEPBIND. :/

> A. Write a new loader
Nonononononononononono. I've seen this thing happening before on Android (you might have heard about the CrazyLinker). From the CrazyLinker experience I can guarantee that it will just bring an insane amount of frustration to you and whoever will follow. You will run into all sort of bugs, you will compete (and race) against the system loader. You'll confuse crash reporting.
I'm not being pessimistic. These are all bugs that I've ever found, being cc-ed to or owned.
Also, if you ever intend to port this code to any other platform, I am sure  you will get quite lot of pushback for introducing a custom loader. Also you will have to maintain N loaders one for each platform. Don't even think that once you write a loader for Linux that will work on Android. It just won't.
In the interest of your (or whoever else) mental sanity I do strongly discourage against this option. One crazylinker is enough for the history of Chrome project for the next 20 years at least.
Fixing odr violations with a custom linker is a recipe for nuclear disaster.
I hope I've been discouraging enough about this option. If that's not the case, let me know, I can do better.


> C. Export tcmalloc's symbols when the allocator shim is in use, so a DSO call to tc_malloc will use the mojo_runner's tcmalloc heap.
As I said in the v1 bug ( crbug.com/594674#c35 ), that's a hacky solution, you just move the problem one step away. This requires you to think about which are all the possible entry points to the allocator, and make sure that they are all trampolined. IMHO it might work but it's quite fragile to maintain.
Also remember that tcmalloc is only used on Linux. on other platforms you will still have similar problems, and doing whatever with tc_* symbols won't make any change there.

>  the worst it can do is crash itself. i.e. there isn't still privileged code running anywhere in the process.
Well, as I showed you in  crbug.com/594674#c35 , one of the problem I found in that experiment is that you silently lose the suicide-on-oom and start passing nullptr's around. I have no idea what else could happen but this wouldn't make me super comfortable.

> B. Stop linking service libraries against the allocator shim.
This is IMHO a clean option. (Note, the *shim* part here is irrelevant. Your problem here is whatever defines malloc. Whether it's the shim, vanilla tcmalloc or anything else it's irrelevant)

All this problem starts, in fact, with the violation of the well established principle that only root executables should define the allocator symbols.
You can stretch it a bit making it so that only the first DT_NEEDED of the root executable defines the allocator  (like we do in component builds, where the allocator is in libbase.so).
Stopping the multi-definition IMHO is the way to go.

Now, there are two ways to achieve this that come to my mind.
One is B, as you say. I know that building twice (With and without use_Allocator=none) is a bit of a pain, but perhaps is the less problematic option on the plate.
Still requires some thinking, I'm sure just building the DSO with use_allocator=none won't just work, but if we deem it's the way to go we can figure out the details. It shouldn't be *too* hard.


The other way to have the allocator stuff being defined only in *some* executables could be
(I need to think a bit more on what I'm about to say, and we need to discuss this with base owners but...) What if:
- we split the allocator bits in a separate static library (say base_allocator.a)
- we create a base_without_allocator target (today's base - allocator)
- we redefine base to be base_without_allocator + base_allocator.a
- we keep linking chrome and all its binaries against base
- (so far, no change, just lot of refactoring work)
- you link mojo_runner against base, and the DSOs you want against base_without_allocator

Conceptually it's clean, but there is quite some work involved, as now the allocator shim (that we use on linux, android and windows) needs some surgery, and the part that goes into the standalone allocator linker unit cannot depend on base. Not sure how complex this surgery would be.

[1]https://docs.google.com/document/d/1V77Kgp_4tfaaWPEZVxNevoD02wXiatnAv7Ssgr0hmjg/edit#

If you should go for accepting a hacky solution, IMHO the "best of the worst" here is:
- PLT-trampoline UncheckedAlloc (which was the root of the original bug) like I did in my attempt in the v1 bug (crrev.com/2279473002)
- PLT-trampoline also the SetCallNewHandlerOnMallocFailure (which is the next thing I discovered was broken)
- PLT-trampoline whatever else enters the allocator or the shim- the api surface shouldn't be too wide.
- Cross your fingers and hope that nobody will break this in future refactorings.

Again, this is neither a nice nor a maintainable solution, so I'm not endorsing it. But if you should run short of ideas, might be the less frightening among all the ones we considered so far.

Haven't read further than the first sentence so far, but

> I believe so far we never considered the use-case of base being linked in more than one linker unit which depends on each other.

I think we just don't support this (?)

After reading a bit more: I don't think the allocator stuff is special, I'd guess that a bunch of more code in base would get confused that its state now lives in two modules. We really never considered supporting linking base statically into several places.

Depending on what you want to do:
* Make mojo_runner not depend on base
* Always ship base as a component (...this will be weird too...)
* Split off whatever part of base you need and make that a component and depend only on that, or make that split-off explicitly support being loaded into several places

Why is mojo_runner its own executable? This will be troublesome if we eg start linking the C++ library statically (which we'll likely end up doing).

I see, so there is other global shim state we need to be concerned with apart from tcmalloc's own.

I agree that not linking the shim into our DSOs sounds like the correct solution after all.

If we actually split the allocator out into its own target I think we'd have to leave it out of //base and require executables to explicitly link in the shim if they want it. Keeping the allocator in //base and adding a //base:without_allocator will essentially mean that we have to duplicate many, many other targets as well (including, say, //content), and at that point using a separate build toolchain for services would seem like a more correct thing to do.

If we go the toolchain route I expect it to roughly double the number of build steps needed to build chrome for Chrome OS, which is pretty unfortunate. Given that it's a low amount of effort to try though, perhaps we should try it.

Barring that, it doesn't seem too conceptually wrong from my perspective to require executable targets to explicitly link in the allocator shim if desired. Most executables don't care anyway and can leave it out, right?

The allocator is special here because it exports global symbols, and it's the only thing which does this. This affects symbol resolution behavior in the loaded DSO.

There aren't any show-stopping issues with duplicated static state (from base or elsewhere) since we can control how it's used in the mojo_runner sources.

Also, the intended purpose of mojo_runner is to be a small executable which loads and runs services from DSOs, with the ability to set up a sandbox before doing so.

If it's supposed to be small, not depending on base might be a good idea anyhow :-)

Where do these DSOs come from? Do they link in base (and whatnot) as well? What's the story about a) C++ runtime libs b) dependencies on system libraries for these DSOs?

Maybe the runner shouldn't depend on base, but that doesn't really address the core issue. The runner should still export these malloc et al symbols if we want services to use an allocator shim, and that means we don't want the service DSOs to export them too.

The DSOs come from the service() GN template (//services/shell/public/cpp/service.gni). They're essentially shared_library targets with some additional metadata. Yes many of them depend on base and whatnot. There's one for ash, for example, and that even depends on content.

The only broken thing here is the dually exported malloc et al symbols.

> If we actually split the allocator out into its own target I think we'd have to leave it out of //base and require executables to explicitly link in the shim if they want it.
thakis@ and I considered this some months ago when I was refactoring the allocator build files. But turns out we have hundreds of executable targets in chrome, and it was hard to maintain and ensure that future executable remember to link in the allocator as well.
The reality is that, so far, all our executable either:
- need the allocator (for security concerns)
- don't care about that.
But, funny thing, brettw reported that when we turned tcmalloc on by default for all executables, that accidentally speeded-up GN by 10%-40% (see  Issue 586444 ). Which became an argument for "why not".

The thing is: your DSO (whatever it is) seems to be the only thing that deliberately does NOT want the allocator, hence why I was proposing that way. Having to manually add an allocator dependency to hundred targets because one doesn't want it is IMHO a bit overkill.

> Keeping the allocator in //base and adding a //base:without_allocator will essentially mean that we have to duplicate many, many other targets as well (including, say, //content), and at that point using a separate build toolchain for services would seem like a more correct thing to do.
So, the thing is that I have still not understood the architecture of this mojo_runner thingy and what is in practice the DSO that is going to be loaded.
From your comments smells like you are trying to kind of officially supported a component-ish build, with the extra difficulty of dynamically dlopening the components.
If that's the case, good luck, I believe component builds are full of ODR violations (regardless of the allocator). :)

At this point what thakis pointed out about statically linking the C++ library becomes quite relevant. 
I need to recheck this but IIRC the C++ library is full of weak global symbols which get deliberately leaked (because that's the way to override things like the global operator new, etc.) If we end up statically linking will you get into the same  sort of troubles with symbol lookup? 

> Maybe the runner shouldn't depend on base, but that doesn't really address the core issue. The runner should still export these malloc et al symbols if we want services to use an allocator shim, and that means we don't want the service DSOs to export them too.

Following thakis suggestion: at this point what if you make mojo_runner *really* small and make it not depend on anything (or just link int libc and use a linker script to prevent any symbol to leak out)?
at that point the dlopen-ed library becomes the effective root of the loader search, and you are back to the nominal chrome case, because you gurantee that:
1. mojo_runner doesn't export any symbol
2. mojo_runner doesn't have any DT_NEEDED dependency that would cause symbol resolution to find some early library.

As long as you dlopen only *one* .so, that might just be *the* solution.

At this point you can keep linking base, libstdc++ and whatnot and I believe that as long as you statically link everything and clean up the symbol table, that will just work (TM).

We do only need to dlopen one DSO per process, and that's very likely to be a permanently acceptable constraint.

mojo_runner still has to do quite a bit of non-trivial stuff. For one thing it does sandbox configuration. It also embeds the mojo system implementation, which negotiates communication with other processes and supports the public mojo C API consumed by the DSOs (the DSOs export an entry point for filling in a small function table of API calls, and this is before calling the service's main entry point.) It sets up a background thread for IPC, and uses things from base like MessageLoop, FD watching, Bind/Callback, etc. It would be unfortunate to duplicate that stuff.

I think guarantee #1 (no exports) is doable if we simply link the runner without the allocator, which is easy enough to manage without split-configuration explosion - mojo_runner has relatively few and fixed dependencies.

I don't fully understand how to satisfy guarantee #2. Won't libc itself be an unavoidable DT_NEEDED dependency? (apologies if i'm missing the obvious, all this is making me a bit dizzy;))

> I don't fully understand how to satisfy guarantee #2. Won't libc itself be an unavoidable DT_NEEDED dependency
Not if you statically link it.

I've been thinking again about trying to solve this some time soon.

The right thing to do seems clearly to be stop linking our service DSOs against the allocator shim. To recap prior discussion, there are really three ways sane to accomplish this:

A) Introduce a separate toolchain configuration where //base does not link against the allocator, and build services with that toolchain. Pro: simple and isolated change, Con: Huge increase to number of targets built in a normal configuration (many targets would be dependencies of both service code and non-service code)

B) Introduce a separate base-without-allocator target, which services and their dependencies must depend on instead of base. Pro: fairly simple, Con: Not well isolated; because a large number of targets are dependencies of both service code and non-service code, these targets would also need to be duplicated to have a no-allocator version.

C) Remove the allocator shim from base and require leaf targets (executables, etc) to explicitly opt into the allocator shim by adding a dependency on it. Pro: none of the toolchain/target bloat of A or B, Con: Easy to forget to add the dependency.

Any other options I'm missing?

I wonder if we could fix the con of C by making it possible to inject deps into 'exe'. Alternatively ban exe some how and add a template that injects the allocation.

> C) Remove the allocator shim from base and require leaf targets (executables, etc) to explicitly opt into the allocator shim by adding a dependency on it. Pro: none of the toolchain/target bloat of A or B, Con: Easy to forget to add the dependency.

Not sure this is *that* easy. base itself needs to know if the shim is enabled or not for things like base/process/memory* (see all the references to BUILDFLAG(USE_EXPERIMENTAL_ALLOCATOR_SHIM)). 
In essence if you move the allocator shim out of base you need base to depend on it, and you are back to the original problem.

> B) Introduce a separate base-without-allocator target, which services and their dependencies must depend on instead of base. Pro: fairly simple, Con: Not well isolated; because a large number of targets are dependencies of both service code and non-service code, these targets would also need to be duplicated to have a no-allocator version.
This will easily get in a dual-base ODR situation as soon as you have something that depends both on services and non services as you say. 

>The right thing to do seems clearly to be stop linking our service DSOs against the allocator shim.
Or stop leaking symbols from mojo_runner? What's the downside of #12, i.e. making mojo_runner hermetic from a loader perspective?
What is the process hosting story for these DSO? Do you expect to have multiple DSOs loaded in the same process or is the runtime model 1 process == 1 dso? 

I would not be comfortable ruling out multiple DSOs per process.

> I would not be comfortable ruling out multiple DSOs per process.
which means that you will have multiple "base" implementations around.

Regardless of the allocator problem, I think it can work only if you guarantee that the runner and the DSOs don't leak symbols (allocator and non).

I think we're OK with the constraint that DSOs must not leak symbols. That's not something we have to worry about today AFAICT beyond the allocator shim, and it's probably something we could eventually check and enforce at load time.

Despite the code size redundancy, I think it's OK for each DSO to have its own base implementation.

Going to move forward with the approach discussed offline with primiano@ a few weeks ago, as a simple PoC demonstrates that it addresses our problem. To summarize:

- We build a thin bootstrap binary which exports no symbols. This will statically link base-without-allocator, libstdc++, etc (the situation on Windows is more flexible). The only thing this binary does is provide a small set of thunks for hooking into base::NativeLibrary support (open, close, resolve symbol)

- We build the service runner itself as a DSO and load this from the bootstrap. It accepts an injection of thunks for the NativeLibrary support above, so any service DSO loading is delegating back to the bootstrap binary.

This allows the service runner and all service DSOs to have whatever dependencies they like, without running into conflicting global exports.

> We build a thin bootstrap binary which exports no symbols. This will statically link base-without-allocator, libstdc++, etc (the situation on Windows is more flexible). The only thing this binary does is provide a small set of thunks for hooking into base::NativeLibrary support (open, close, resolve symbol)

Why do you need base without allocator? since this binary needs to just do a dlopen + dlsym can you just NOT use neither base nor any stdlib?

allocator shim is busted

statically link base-without-allocator, libstdc++, etc (the situation on
Windows is more flexible). The only thing this binary does is provide a
small set of thunks for hooking into base::NativeLibrary support (open,
close, resolve symbol)

do a dlopen + dlsym can you just NOT use neither base nor any stdlib?

We can, but we also do things like get the executable path, parse path
strings, and use native library support on multiple platforms. We could of
course only use this strategy on POSIX, but it just makes the runner code
messier.

I reimplemented that stuff for the bootstrap binary, but it made me pretty
unhappy to be duplicating things in base.

I'm happy to move forward with duplication if that's going to be less
controversial.

> The only thing this binary does is provide a
small set of thunks for hooking into base::NativeLibrary support (open,
close, resolve symbol)

Can you not do that stuff in the runner.so (or whatever name, I mean the first DSO you load from the exe)? I was imagining the runner.exe to be as simple as:
dlopen("runner.so"); *dlsym("runner_main")();

allocator shim is busted

first DSO you load from the exe)? I was imagining the runner.exe to be as
simple as:

Well sure, and that's essentially what it is.

Note that we need to be more intelligent about the path of runner.so. Right
now I have code which assumes it's in the current executable's path,
duplicating PathService and FilePath stuff.

Some amount of logging is useful in case anything goes wrong, but of course
printf would be sufficient here.

Finally, I was thinking the runner DSO would need to thunk out to the
bootstrap to load libraries, but as long as libdl is dynamically linked
everywhere that's probably unnecessary.

So there's a bit of a complication with this approach (surprise surprise): libdl depends on libc, and if the bootstrap depends on libc, all loaded DSOs will use libc's malloc, free, etc, rather than their shim's exports.

Even if the bootstrap is statically linked, static dlopen *still* requires the right glibc version to be available dynamically at runtime (presumably it actually opens glibc itself), which defeats the purpose of static linkage anyway.

Ok I think I found what I really wanted during our live chat.
You don't need necessarily a hermetic runner.exe (which seems a pain for the reason you describe). You can create a linker isolate using dlmopen(LM_ID_NEWLM, "lib.so")

I created a full repro case simulating the case of loading chrome as a dso, and in turn calling a third_party dso from the main dso here:

https://drive.google.com/drive/folders/0B3KuDeqD-lVJRmRmVXRObXZMcVk?usp=sharing

It seem to do what we want.
(P.S: Ignore the syscall stuff and sys_write there, they are irrelevan and come from a previous attempt of statically link libdl.)


LD_LIBRARY_PATH=/home/primiano/lib ./runner

Loading libdso1.so
dlopen: OK
dlsym: OK
In DSO #1
  internal malloc #1
 > in libsub
  internal malloc #1

Loading libdso2.so
dlopen: OK
dlsym: OK
In DSO #2
  internal malloc #2
 > in libsub
  internal malloc #2

So what I checked is that:
the fact that the runner depends on libc.so is irrelevant. Both the dso-s and the nested .so see the malloc symbol defined by the dso.
Each of the two dso and nested .so see the malloc() symbols from its own dso (so in practice each dso will end up having its own tcmalloc definition and its own tcmalloc heap, and will propagate that to third party libraries like libcups).

Thanks for this suggestion. It seems that by design isolated namespaces are what we want, but I've already hit some unfortunate snags and I'm worried that dlmopen support might be a bit tenuous across systems.

On one Ubuntu host I have, a simple test crashes within dlmopen. The library being loaded depends on //base and so has several interesting dependencies. From a kernel log the crash appears to be in glib initialization with a call to g_splice_alloc. Maybe just a bug in this version of glib, but it does set off some alarms about what subtleties might lead to something like this.

On my goobuntu host the dlmopen is successful and indeed all our standard test cases are working just fine: we can malloc and free, tc_malloc and free, etc. However, the first new thread that's spawned ends up crashing in tcmalloc::ThreadCache::CreateCacheIfNecessary on presumably its first heap allocation.

I haven't had time to dig further into either of these cases yet.

One (possibly quite stupid) thought I had regarding this problem: maybe we could just build standalone service executables for linux/chromeos and use execve after sandbox setup?

Hmm that has probably something to do with pthread_setspecific and TLS.
One thing that I just realized: regardless of allocator, I think that if you host multiple DSOs in the same process you really need to load each of them in different isolates and have separate instances.
The problem is this: what is your threading model here? I imagine every DSO will have its own "main thread" right? If this is the case, today we use a bunch of third party libraries (cups, dbus, bluez) and we use some of them only on one thread cause they might not be thread safe.
Now if you end up having two main threads in the same process referring to the same copy of libdbus, you will violate this and start using that effectively from multiple threads.

> One (possibly quite stupid) thought I had regarding this problem: maybe we could just build standalone service executables for linux/chromeos and use execve after sandbox setup?
I am not a security expert but I think that:
Seccomp BPF supports maintaining the seccomp across exec* [1] but that assumes that the filtering happens in another process. I think you can't possibly filter from the same process if you replace the process image with exec. At the same time, I think that currently chrome uses a filtering thread in-process. No idea if would be feasible to move that out-of-process. It's something you need to discuss with chrome-security but IMHO doesn't seem to be something that will just-work (TM).

One question is: why are you having this runner + dso architecture? Can't you make your services full executables in the first place, and have your runner being a static library that you have to link-in which gives you the main() entry point?
Even if you manage to successfully have multiple DSOs loaded in the same process image, what would be the benefit at that point? From this bug looks you still want these DSOs to be self-contained and independent from each other. Which means that they will have their own heaps and their own libs. But at this point, what is the gain? You won't save any memory and will jeopardize security and stability.

[1] https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt

It's much less about loading multiple DSOs than it is about running arbitrary native code in a sandbox. But perhaps that goal already presents intractable security risks.

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

commit d65d4dc16cdd2293d44b943184fc267c7bf9ffe0
Author: rockot <rockot@chromium.org>
Date: Sat Dec 10 02:09:05 2016

Build services as standalone executables

Cleans up a bunch of service manager details which exist to support
the currently untenable goal of dynamically loading service binaries
in a common host executable.

Changes services to instead build as standalone executables, and
teaches the service manager how to launch them.

BUG= 642879 

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

[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/chrome/app/mash/BUILD.gn
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/chrome/app/mash/mash_runner.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/chrome/test/base/mash_browser_tests_main.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/chrome/test/base/mojo_test_connector.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/content/browser/service_manager/service_manager_context.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/catalog/reader.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/background/background_service_manager_main.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/native_runner.h
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/lib/service_runner.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/service.gni
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/service.h
[add] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/standalone_service/BUILD.gn
[add] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/standalone_service/DEPS
[rename] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/standalone_service/linux_sandbox.cc
[rename] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/standalone_service/linux_sandbox.h
[rename] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/standalone_service/mach_broker.cc
[rename] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/standalone_service/mach_broker.h
[add] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/standalone_service/main.cc
[rename] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/standalone_service/standalone_service.cc
[add] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/standalone_service/standalone_service.h
[add] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/standalone_service/switches.cc
[add] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/public/cpp/standalone_service/switches.h
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/runner/BUILD.gn
[delete] https://crrev.com/75e3ed0f6a7521437691659d27664576906c604d/services/service_manager/runner/child/BUILD.gn
[delete] https://crrev.com/75e3ed0f6a7521437691659d27664576906c604d/services/service_manager/runner/child/manifest.json
[delete] https://crrev.com/75e3ed0f6a7521437691659d27664576906c604d/services/service_manager/runner/child/test_native_main.cc
[delete] https://crrev.com/75e3ed0f6a7521437691659d27664576906c604d/services/service_manager/runner/child/test_native_main.h
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/runner/host/BUILD.gn
[delete] https://crrev.com/75e3ed0f6a7521437691659d27664576906c604d/services/service_manager/runner/host/child_process.cc
[delete] https://crrev.com/75e3ed0f6a7521437691659d27664576906c604d/services/service_manager/runner/host/child_process.h
[delete] https://crrev.com/75e3ed0f6a7521437691659d27664576906c604d/services/service_manager/runner/host/child_process_base.h
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/runner/host/child_process_host.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/runner/host/child_process_host.h
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/runner/host/child_process_host_unittest.cc
[add] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/runner/host/host_test_service_main.cc
[add] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/runner/host/host_test_service_manifest.json
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/runner/host/host_unittests.cc
[delete] https://crrev.com/75e3ed0f6a7521437691659d27664576906c604d/services/service_manager/runner/host/in_process_native_runner.cc
[delete] https://crrev.com/75e3ed0f6a7521437691659d27664576906c604d/services/service_manager/runner/host/in_process_native_runner.h
[delete] https://crrev.com/75e3ed0f6a7521437691659d27664576906c604d/services/service_manager/runner/host/in_process_native_runner_unittest.cc
[delete] https://crrev.com/75e3ed0f6a7521437691659d27664576906c604d/services/service_manager/runner/host/native_library_runner.cc
[delete] https://crrev.com/75e3ed0f6a7521437691659d27664576906c604d/services/service_manager/runner/host/native_library_runner.h
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/runner/host/out_of_process_native_runner.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/runner/host/out_of_process_native_runner.h
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/service_manager.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/standalone/BUILD.gn
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/standalone/context.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/standalone/desktop/main_helper.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/switches.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/switches.h
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/tests/connect/BUILD.gn
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/tests/connect/connect_test_exe.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/tests/lifecycle/BUILD.gn
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/tests/lifecycle/lifecycle_exe.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/tests/lifecycle/package.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/tests/service_manager/BUILD.gn
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/tests/service_manager/embedder.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/service_manager/tests/service_manager/target.cc
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/tracing/BUILD.gn
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/services/ui/BUILD.gn
[modify] https://crrev.com/d65d4dc16cdd2293d44b943184fc267c7bf9ffe0/testing/buildbot/chromium.android.json

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

commit 3d1922bf7e1a53616f82c630eb6c0958eb574386
Author: rockot <rockot@chromium.org>
Date: Sat Dec 10 04:38:46 2016

Revert of Build services as standalone executables (patchset #14 id:260001 of https://codereview.chromium.org/2557213002/ )

Reason for revert:
Lots of test failures - ICU data not being found in service processes.

Original issue's description:
> Build services as standalone executables
>
> Cleans up a bunch of service manager details which exist to support
> the currently untenable goal of dynamically loading service binaries
> in a common host executable.
>
> Changes services to instead build as standalone executables, and
> teaches the service manager how to launch them.
>
> BUG= 642879 
>
> Review-Url: https://codereview.chromium.org/2557213002

TBR=ben@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 642879 

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

[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/chrome/app/mash/BUILD.gn
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/chrome/app/mash/mash_runner.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/chrome/test/base/mash_browser_tests_main.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/chrome/test/base/mojo_test_connector.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/content/browser/service_manager/service_manager_context.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/catalog/reader.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/background/background_service_manager_main.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/native_runner.h
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/public/cpp/lib/service_runner.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/public/cpp/service.gni
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/public/cpp/service.h
[delete] https://crrev.com/5a8cd7c774f376bc9f51cceea12aaed1a1edb87e/services/service_manager/public/cpp/standalone_service/BUILD.gn
[delete] https://crrev.com/5a8cd7c774f376bc9f51cceea12aaed1a1edb87e/services/service_manager/public/cpp/standalone_service/DEPS
[delete] https://crrev.com/5a8cd7c774f376bc9f51cceea12aaed1a1edb87e/services/service_manager/public/cpp/standalone_service/main.cc
[delete] https://crrev.com/5a8cd7c774f376bc9f51cceea12aaed1a1edb87e/services/service_manager/public/cpp/standalone_service/standalone_service.h
[delete] https://crrev.com/5a8cd7c774f376bc9f51cceea12aaed1a1edb87e/services/service_manager/public/cpp/standalone_service/switches.cc
[delete] https://crrev.com/5a8cd7c774f376bc9f51cceea12aaed1a1edb87e/services/service_manager/public/cpp/standalone_service/switches.h
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/BUILD.gn
[add] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/child/BUILD.gn
[add] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/child/manifest.json
[add] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/child/test_native_main.cc
[add] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/child/test_native_main.h
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/BUILD.gn
[add] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/child_process.cc
[add] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/child_process.h
[rename] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/child_process_base.cc
[add] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/child_process_base.h
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/child_process_host.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/child_process_host.h
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/child_process_host_unittest.cc
[delete] https://crrev.com/5a8cd7c774f376bc9f51cceea12aaed1a1edb87e/services/service_manager/runner/host/host_test_service_main.cc
[delete] https://crrev.com/5a8cd7c774f376bc9f51cceea12aaed1a1edb87e/services/service_manager/runner/host/host_test_service_manifest.json
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/host_unittests.cc
[add] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/in_process_native_runner.cc
[add] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/in_process_native_runner.h
[add] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/in_process_native_runner_unittest.cc
[rename] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/linux_sandbox.cc
[rename] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/linux_sandbox.h
[rename] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/mach_broker.cc
[rename] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/mach_broker.h
[add] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/native_library_runner.cc
[add] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/native_library_runner.h
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/out_of_process_native_runner.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/runner/host/out_of_process_native_runner.h
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/service_manager.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/standalone/BUILD.gn
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/standalone/context.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/standalone/desktop/main_helper.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/switches.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/switches.h
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/tests/connect/BUILD.gn
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/tests/connect/connect_test_exe.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/tests/lifecycle/BUILD.gn
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/tests/lifecycle/lifecycle_exe.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/tests/lifecycle/package.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/tests/service_manager/BUILD.gn
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/tests/service_manager/embedder.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/service_manager/tests/service_manager/target.cc
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/tracing/BUILD.gn
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/services/ui/BUILD.gn
[modify] https://crrev.com/3d1922bf7e1a53616f82c630eb6c0958eb574386/testing/buildbot/chromium.android.json

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

commit b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea
Author: rockot <rockot@chromium.org>
Date: Sat Dec 10 19:29:35 2016

Build services as standalone executables

Cleans up a bunch of service manager details which exist to support
the currently untenable goal of dynamically loading service binaries
in a common host executable.

Changes services to instead build as standalone executables, and
teaches the service manager how to launch them.

BUG= 642879 

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

[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/chrome/app/mash/BUILD.gn
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/chrome/app/mash/mash_runner.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/chrome/test/base/mash_browser_tests_main.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/chrome/test/base/mojo_test_connector.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/content/browser/service_manager/service_manager_context.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/catalog/reader.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/background/background_service_manager_main.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/native_runner.h
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/lib/service_runner.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/service.gni
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/service.h
[add] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/standalone_service/BUILD.gn
[add] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/standalone_service/DEPS
[rename] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/standalone_service/linux_sandbox.cc
[rename] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/standalone_service/linux_sandbox.h
[rename] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/standalone_service/mach_broker.cc
[rename] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/standalone_service/mach_broker.h
[add] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/standalone_service/main.cc
[rename] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/standalone_service/standalone_service.cc
[add] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/standalone_service/standalone_service.h
[add] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/standalone_service/switches.cc
[add] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/public/cpp/standalone_service/switches.h
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/runner/BUILD.gn
[delete] https://crrev.com/acd3292620e912700a18c15346a9b1f391493279/services/service_manager/runner/child/BUILD.gn
[delete] https://crrev.com/acd3292620e912700a18c15346a9b1f391493279/services/service_manager/runner/child/manifest.json
[delete] https://crrev.com/acd3292620e912700a18c15346a9b1f391493279/services/service_manager/runner/child/test_native_main.cc
[delete] https://crrev.com/acd3292620e912700a18c15346a9b1f391493279/services/service_manager/runner/child/test_native_main.h
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/runner/host/BUILD.gn
[delete] https://crrev.com/acd3292620e912700a18c15346a9b1f391493279/services/service_manager/runner/host/child_process.cc
[delete] https://crrev.com/acd3292620e912700a18c15346a9b1f391493279/services/service_manager/runner/host/child_process.h
[delete] https://crrev.com/acd3292620e912700a18c15346a9b1f391493279/services/service_manager/runner/host/child_process_base.h
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/runner/host/child_process_host.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/runner/host/child_process_host.h
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/runner/host/child_process_host_unittest.cc
[add] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/runner/host/host_test_service_main.cc
[add] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/runner/host/host_test_service_manifest.json
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/runner/host/host_unittests.cc
[delete] https://crrev.com/acd3292620e912700a18c15346a9b1f391493279/services/service_manager/runner/host/in_process_native_runner.cc
[delete] https://crrev.com/acd3292620e912700a18c15346a9b1f391493279/services/service_manager/runner/host/in_process_native_runner.h
[delete] https://crrev.com/acd3292620e912700a18c15346a9b1f391493279/services/service_manager/runner/host/in_process_native_runner_unittest.cc
[delete] https://crrev.com/acd3292620e912700a18c15346a9b1f391493279/services/service_manager/runner/host/native_library_runner.cc
[delete] https://crrev.com/acd3292620e912700a18c15346a9b1f391493279/services/service_manager/runner/host/native_library_runner.h
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/runner/host/out_of_process_native_runner.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/runner/host/out_of_process_native_runner.h
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/service_manager.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/standalone/BUILD.gn
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/standalone/context.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/standalone/desktop/main_helper.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/switches.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/switches.h
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/tests/connect/BUILD.gn
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/tests/connect/connect_test_exe.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/tests/lifecycle/BUILD.gn
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/tests/lifecycle/lifecycle_exe.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/tests/lifecycle/package.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/tests/service_manager/BUILD.gn
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/tests/service_manager/embedder.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/service_manager/tests/service_manager/target.cc
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/tracing/BUILD.gn
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/services/ui/BUILD.gn
[modify] https://crrev.com/b8b2bfc86e7c3729593c14806c8d9f9fe08bb6ea/testing/buildbot/chromium.android.json

Standalone service binaries working again. We can revisit dynamic loading if and when it becomes a priority.

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

commit c09cf5f93bd8926d3f3b8202c820e57b6e319b79
Author: sky <sky@chromium.org>
Date: Thu Dec 15 18:57:25 2016

Reenables (and fixs) two mash tests

These were disabled because of issues with the allocator shim. That's
been fixed, so they can be reenabled again.

BUG= 642879 
TEST=test only changes
R=msw@chromium.org

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

[modify] https://crrev.com/c09cf5f93bd8926d3f3b8202c820e57b6e319b79/ash/mus/app_launch_unittest.cc
[modify] https://crrev.com/c09cf5f93bd8926d3f3b8202c820e57b6e319b79/ash/mus/window_manager_unittest.cc