IIUC we can hook the ServiceManager in the utility process, at least, to capture GetInterface() calls, as a rough approximation.

cc: ivanpe@

Ivan, do you know an appropriate person that this could be routed to?

We have an uptick in Utility crashes (crbug.com/690494) and this info would help track those down.

This seems more of a Mojo-side thing than a Crash thing; FWIW I'd actually
planned to look at it myself.

+ben

Ben, who is the right person on Mojo to own this? This is needed to diagnose an uptick in utility process crashes that's affecting Stable channel on multiple platforms:
https://bugs.chromium.org/p/chromium/issues/detail?id=690494

+jam

Ken: can you take a look?

I don't think it's reasonable to track "hosted services" as a general property of any arbitrary running process, e.g. as some kind of global state maintained by common service code. At the end of the day, a service is quite literally just another binding endpoint.

It does seem reasonable to track this for utility processes specifically, since when used for services they host a single service exclusively, and that happens through a common codepath.

Have said all that, I suspect this will turn out to be completely irrelevant for the immediate motivating issue: bug 690494 indicates that the crash spike comes exclusively from unsandboxed utility processes, but the only registered service which uses an unsandboxed utility process is the shape_detection service, which: A) didn't even land until after M56 branch and B) is only exposed behind experimental flags anyway.

After looking a bit closer, I'm lowering the priority here as this does not seem like a useful change to make right now.

Today in production, image_decoder is the only service which runs in a utility process, and it's always sandboxed.

By the time we add more out-of-process services, I anticipate that we won't even be using the utility process to launch them anymore. I'll reserve this as something to add to service processes as they become available.

Re #10: Are you sure? I thought we at least run the Windows 10 pinned-to-taskbar detection code in an unsandboxed utility process, for example?

Maybe we do, but what does that have to do with mojo services?

Re #12: The is-pinned-to-taskbar helper is a utility process implementing a mojo interface (ShellHandler). Knowing that the crashed utility process had an active instance of chrome::mojom::ShellHandler would help identify why it was running in the first place so we can e.g. say "oh, we expect that to crash relatively often because it gets shell extension DLLs loaded into it", for example.

Oh sorry, I think it's a semantic issue. You mean interfaces not services -
services are a higher layer than individual interfaces, where it might
actually make sense to reason about what "service" a given process is.

In general I do not think it is reasonable to have a crash key which
accumulates all bound Mojo interfaces in a process. That is a very large
set for anything but the utility process, and even then there is nothing
which stops one interface from being used to bind additional interfaces:
there's no common code path through which all extant interface bindings are
established.

Why are stack traces not useful in this case? If we step back and ignore
the detail of Mojo being used for IPC, how would this issue be investigated
when using classic Chrome IPC?

IIUC with classic Chrome IPC we'd tell the utility process which utility we
want it to run, and then start firing IPCs at that; with Mojo we
effectively have "generic" utility processes which we then request
interfaces from to assign the process a particular purpose. So for Chrome
IPC the command-line provides a clue even if the crash stacks are too
messed up to diagnose (as is often the case when third-party software
stomps things).

Not really, no. Utility process has always been a bag of random IPC.

Based on the discussion in this bug I don't think there's work to do here.

Issue 866830 has been merged into this issue.