Mojo debugging tools for remote endpoint behavior |
||
Issue descriptionWhen debugging why a mojo connection was unintentionally closed, knowing the original reason for the closure can save the developer a lot of time. For example, in issue 694807 there's was a cascade of pipe closures, starting with a Service pipe, followed by an InterfaceProvider pipe, and finally a PrefStoreRegistry pipe. Someone listening on failures on the latter might think that something went wrong in the PrefStoreRegistry impl, when in fact that impl was never created in the first place because the Service connection failed. Finding the real cause here can be time consuming. If we could somehow communicate the reason for a pipe closure (e.g. by giving names of the pipes that closed before or providing a the stack frame trace at the point of closure) that would be helpful.
,
Dec 5
I will also lump method call stacks into this as well - we can have a last_call_stack control message similar to the ones already listed.
,
Dec 5
,
Dec 5
+staphany@. This could be another interesting bug to start looking at. It's a pretty significant ramp up from making mechanical changes, and it will likely result in several non-trivial CLs. It will probably also make a lot of developers very happy. |
||
►
Sign in to add a comment |
||
Comment 1 by rockot@google.com
, Nov 15Labels: -Pri-3 Pri-2
Status: Available (was: Untriaged)
Summary: Mojo debugging tools for remote endpoint behavior (was: Report the original cause of a pipe being closed)
Triaging to P2. This or something similar is a frequent feature request from developers. In general, people want a way to know why the other end of a pipe is being closed or who has bound it. Supporting this would have a pretty high degree of runtime overhead, but we could restrict such it to DCHECK builds to make it more palatable. We should be able to implement such things this at the bindings layer using interface control messages. I could imagine defining e.g. new "Run" (i.e. one-way) control messages, so we'd have (in mojo/public/interfaces/bindings/interface_control_messages.mojom): union RunInput { QueryVersion query_version; FlushForTesting flush_for_testing; [EnableIf=is_dcheck_enabled] string close_stack; [EnableIf=is_dcheck_enabled] string unbind_stack; }; and we can send stringified base::debug::StackTraces from various places wherever these things can happen. Then of course we can expose the same debugging information as it's received by the other side.