Asynchronous AcceptInvitation failure should be detectable |
|||||
Issue descriptionIn issue 691118, the Android Seccomp policy on i386 was causing SetParentPipeHandle to fail. Because failure in SetParentPipeHandle is only reported on the first failed send, though, this resulted in the main thread's MessageLoop being QuitWhenIdle() due to a ChildThreadImpl::OnChannelError(). This led to no easily detectible crash, and instead it manifested merely as a System.exit(0). rockot@ wrote at https://bugs.chromium.org/p/chromium/issues/detail?id=691118#c21: "This is expected behavior, but it probably makes sense to expose SetParentPipeHandle failure (be it synchronous or asynchronous) so content could be more proactive about crashing in that case." Having a failure callback would be helpful, so Chrome could LOG(FATAL) under that condition, rather than having the renderer just exit quietly.
,
May 29 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 17
,
Nov 15
Triaging, re-titling appropriately for naming of things in the ABI. Still potentially valid, though beyond the initial synchronous AcceptInvitation step, there are so many potential points of failure -- many of which are not related to AcceptInvitation itself -- that we ought to consider a more general purpose API for pushing internal system events to the Mojo consumer.
,
Nov 15
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by roc...@chromium.org
, May 29 2017Owner: ----
Status: Available (was: Assigned)