New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 604912 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Media services should not outlive MediaService

Project Member Reported by sande...@chromium.org, Apr 19 2016

Issue description

Currently, services created by a ServiceFactory do not hold a reference to the MojoMediaApplication. Thus it's not certain what the destruction order may be when a client disappears.

Since some services assume that the MojoMediaApplication will outlive them (by depending on resources that it owns), the dependency should be made explicit.
 

Comment 1 by xhw...@chromium.org, Oct 19 2016

Owner: xhw...@chromium.org
Status: Started (was: Available)
Recently I hit this as well. I think it makes sense for created services also hold a reference to the MojoMediaApplication.

Comment 2 by xhw...@chromium.org, Oct 21 2016

Summary: Media services should not outlive MediaService (was: Services should not outlive MojoMediaApplication)

Comment 3 by xhw...@chromium.org, Oct 21 2016

Cc: roc...@chromium.org
Labels: -Pri-3 Pri-2
Re #1: The issue I hit is actually not related to the original issue reported here.

That being said, the original issue is legit. Here are some issues that I can think of:

1. MediaService owns MojoMediaClient, and is passing raw pointers of MojoMediaClient to ServiceFactoryImpl. This is okay since ServiceFactoryImpl owns a ServiceContextRef to MediaService. However, it seems ServiceFactoryImpl can pass the MojoMediaClient raw pointer to other media interface implementations (MII, e.g. MojoVideoDecoderService) as well. Note that MojoVideoDecoderService is strongly bound to the pipe so in theory it can outlive ServiceFactoryImpl.

2. ServiceFactoryImpl can also pass some other raw pointers to MII, e.g. the remote interface provider (as in MojoCdmService).

In summary, MII should outlive both the MediaService, and the ServiceFactoryImpl.

Note that today, in the render process ServceFactory is owned by RenderFrameImpl, since "frame" should be destroyed after media element, we should be okay most of the time, but I guess there's no guarantee.

Note that passing the ServiceContextRef to MII (as suggested in #1) won't work, because that only guarantees that MediaService will be destructed after MII, but can't ensure ServiceFactoryImpl will be destructed after MII.

Maybe we should not use StrongBindings for MII, and instead, just let ServiceFactoryImpl own MII and use weak bindings for MII.

rockot: Any recommendations?

Comment 4 by roc...@chromium.org, Oct 25 2016

This sounds like a general object lifetime management issue, and you have a
number options for solving it. If none of these impls are useful without an
active MojoMediaClient object, and the only reason you'd keep a
ServiceFactoryImpl alive would be to keep a MojoMediaClient alive, maybe
SFI shouldn't own MMC.

But it's really your call. I don't think there are any special constraints
or exceptions as a result of using Mojo.

Treat StrongBinding usage as equivalent to self-owned global state. If
strongly-bound things need a reference to some shared state, that shared
state should itself probably be either leaky or ref-counted, or expose some
way to be notified when it's going away so you can forcibly cleanup its
dependents.

Comment 5 by xhw...@chromium.org, Nov 23 2016

Cc: alokp@chromium.org ben@chromium.org
I have some thoughts, which comes with more questions :)

I posted my question at: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-mojo/K9UsRyKpfHQ
Project Member

Comment 6 by bugdroid1@chromium.org, Nov 29 2016

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

commit a2db52064245983d71338e51d330edf256418e81
Author: xhwang <xhwang@chromium.org>
Date: Tue Nov 29 22:06:46 2016

media: Add |bad_message_cb_| to MojoRendererService

This helps move the StrongBindingPtr out of MojoRendererService, so that
we can bind MojoRendererService using other type of bindings, e.g.
mojo::Binding.

When we do use MojoRendererService::Create(), which uses
mojo::StrongBinding, now the StrongBindingPtr isimplicitly owned by the
MojoRendererService through the |bad_message_cb_|.

BUG= 604912 ,669606
TEST=Covered by media_mojo_unittests

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

[modify] https://crrev.com/a2db52064245983d71338e51d330edf256418e81/media/mojo/clients/mojo_renderer_unittest.cc
[modify] https://crrev.com/a2db52064245983d71338e51d330edf256418e81/media/mojo/services/mojo_renderer_service.cc
[modify] https://crrev.com/a2db52064245983d71338e51d330edf256418e81/media/mojo/services/mojo_renderer_service.h

Project Member

Comment 7 by bugdroid1@chromium.org, Nov 30 2016

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

commit e557531d68bbd31b40c2b5c8daa70638c60710c7
Author: xhwang <xhwang@chromium.org>
Date: Wed Nov 30 07:51:30 2016

media: Fix lifetime of InterfaceFactoryImpl and created impls

Makes sure that when InterfaceFactoryImpl is destructed, all mojo
interface implemenations (e.g. MojoAudioDecoderService) are destructed.

To achieve this, a helper class StrongBindingSet is introduced such
that:
- When connection error happens, the entry will be removed from the
  binding set, and the bound impl object will be destructed.
- When StrongBindingSet is destructed, it'll destruct all outstanding
  impl objects in the binding set.

BUG= 604912 
TEST=Added a unittest for StrongBindingSet.

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

[modify] https://crrev.com/e557531d68bbd31b40c2b5c8daa70638c60710c7/media/mojo/BUILD.gn
[modify] https://crrev.com/e557531d68bbd31b40c2b5c8daa70638c60710c7/media/mojo/services/BUILD.gn
[modify] https://crrev.com/e557531d68bbd31b40c2b5c8daa70638c60710c7/media/mojo/services/interface_factory_impl.cc
[modify] https://crrev.com/e557531d68bbd31b40c2b5c8daa70638c60710c7/media/mojo/services/interface_factory_impl.h
[modify] https://crrev.com/e557531d68bbd31b40c2b5c8daa70638c60710c7/media/mojo/services/mojo_renderer_service.cc
[modify] https://crrev.com/e557531d68bbd31b40c2b5c8daa70638c60710c7/media/mojo/services/mojo_renderer_service.h
[add] https://crrev.com/e557531d68bbd31b40c2b5c8daa70638c60710c7/media/mojo/services/strong_binding_set.h
[add] https://crrev.com/e557531d68bbd31b40c2b5c8daa70638c60710c7/media/mojo/services/strong_binding_set_unittest.cc

Comment 8 by xhw...@chromium.org, Nov 30 2016

Status: Fixed (was: Started)
Project Member

Comment 9 by bugdroid1@chromium.org, Nov 30 2016

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

commit 0aa7ee95d17f6864aa9cb1e9bd8caf58baf286c4
Author: xhwang <xhwang@chromium.org>
Date: Wed Nov 30 19:12:11 2016

media: Fix a typo in interface_factory_impl.h

This was introduced in
https://chromiumcodereview.appspot.com/2530613003/

TBR=sandersd@chromium.org
BUG= 604912 

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

[modify] https://crrev.com/0aa7ee95d17f6864aa9cb1e9bd8caf58baf286c4/media/mojo/services/interface_factory_impl.h

Sign in to add a comment