WebMediaPlayer{Android,Impl}: RenderFrameObserver instead of RVO/ML::DestructionObserver.

WebMediaPlayer{Android,Impl}: use RenderFrameObserver instead of ML::DestructionObserver/RenderViewObserver.

RenderThreadImpl is torn down before the main thread's MessageLoop is, and some
of WebMediaPlayerAndroid's dependencies require the render thread to still be
alive, so move its tear-down to earlier in the process.
This is the Android version of r240125 which fixed the same bug in
WebMediaPlayerImpl, but forgot that WebMediaPlayerAndroid is a fork.

Since RenderViewObserver is apparently out of favor nowadays, use RenderFrameObserver.

BUG=338393, 304967, 338481
[Previously committed PS#3 as r248115 and rolled back in r248128]

[email protected], [email protected], [email protected], [email protected]

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=248321

[Ami GONE FROM CHROMIUM, 2014-01-27 18:45:59]

@scherkus: please review
@piman: please OWNERS c/r/r_v_i.cc
@qinmin: FYI

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
File content/renderer/media/android/webmediaplayer_android.h (right):

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
content/renderer/media/android/webmediaplayer_android.h:70: blink::WebFrame*
frame,
FTR whitespace changes here are [git cl format]'s idea.

[piman, 2014-01-27 19:00:16]

LGTM from the lifetime pov, but my understanding is that we're trying to remove
RenderViewObserver. I'm not sure what is the agreed upon replacement pattern, so
+jam for that.

[scherkus (not reviewing), 2014-01-27 19:10:06]

lgtm w/ nits


re: RenderViewObserver ... perhaps there's a yet-to-be-written frame-based
observer to support the out-of-process-frame work?

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
File content/renderer/media/android/webmediaplayer_android.cc (right):

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
content/renderer/media/android/webmediaplayer_android.cc:76:
content::RenderView* render_view,
ditto s/content:://g

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
File content/renderer/media/android/webmediaplayer_android.h (right):

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
content/renderer/media/android/webmediaplayer_android.h:16: #include
"base/message_loop/message_loop.h"
now that we don't inherit from base::MessageLoop::DestructionObserver we
miiiighhhtt be able to replace this #include with a fwd decl of
base::MessageLoopProxy

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
content/renderer/media/android/webmediaplayer_android.h:58: public
content::RenderViewObserver,
s/content::// (you're inside content!)

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
content/renderer/media/android/webmediaplayer_android.h:182: //
content::RenderViewObserver implementation.
nit: s/content::// if you want

[Ami GONE FROM CHROMIUM, 2014-01-27 19:27:03]

Thanks for the reviews.

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
File content/renderer/media/android/webmediaplayer_android.cc (right):

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
content/renderer/media/android/webmediaplayer_android.cc:76:
content::RenderView* render_view,
On 2014/01/27 19:10:06, scherkus wrote:
> ditto s/content:://g

Done.

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
File content/renderer/media/android/webmediaplayer_android.h (right):

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
content/renderer/media/android/webmediaplayer_android.h:16: #include
"base/message_loop/message_loop.h"
On 2014/01/27 19:10:06, scherkus wrote:
> now that we don't inherit from base::MessageLoop::DestructionObserver we
> miiiighhhtt be able to replace this #include with a fwd decl of
> base::MessageLoopProxy

Done.

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
content/renderer/media/android/webmediaplayer_android.h:58: public
content::RenderViewObserver,
On 2014/01/27 19:10:06, scherkus wrote:
> s/content::// (you're inside content!)

Done.

https://codereview.chromium.org/137243005/diff/1/content/renderer/media/andro...
content/renderer/media/android/webmediaplayer_android.h:182: //
content::RenderViewObserver implementation.
On 2014/01/27 19:10:06, scherkus wrote:
> nit: s/content::// if you want

Done.

[commit-bot: I haz the power, 2014-01-27 19:28:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/137243005/40001

[piman, 2014-01-27 20:09:32]

On Mon, Jan 27, 2014 at 11:10 AM, <[email protected]> wrote:

> lgtm w/ nits
>
>
> re: RenderViewObserver ... perhaps there's a yet-to-be-written frame-based
> observer to support the out-of-process-frame work?
>

RenderFrameObserver exists, if that's what could be applicable here.

Antoine


>
>
> https://codereview.chromium.org/137243005/diff/1/content/
> renderer/media/android/webmediaplayer_android.cc
> File content/renderer/media/android/webmediaplayer_android.cc (right):
>
> https://codereview.chromium.org/137243005/diff/1/content/
> renderer/media/android/webmediaplayer_android.cc#newcode76
> content/renderer/media/android/webmediaplayer_android.cc:76:
> content::RenderView* render_view,
> ditto s/content:://g
>
>
> https://codereview.chromium.org/137243005/diff/1/content/
> renderer/media/android/webmediaplayer_android.h
> File content/renderer/media/android/webmediaplayer_android.h (right):
>
> https://codereview.chromium.org/137243005/diff/1/content/
> renderer/media/android/webmediaplayer_android.h#newcode16
> content/renderer/media/android/webmediaplayer_android.h:16: #include
> "base/message_loop/message_loop.h"
> now that we don't inherit from base::MessageLoop::DestructionObserver we
> miiiighhhtt be able to replace this #include with a fwd decl of
> base::MessageLoopProxy
>
> https://codereview.chromium.org/137243005/diff/1/content/
> renderer/media/android/webmediaplayer_android.h#newcode58
> content/renderer/media/android/webmediaplayer_android.h:58: public
> content::RenderViewObserver,
> s/content::// (you're inside content!)
>
> https://codereview.chromium.org/137243005/diff/1/content/
> renderer/media/android/webmediaplayer_android.h#newcode182
> content/renderer/media/android/webmediaplayer_android.h:182: //
> content::RenderViewObserver implementation.
> nit: s/content::// if you want
>
> https://codereview.chromium.org/137243005/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].

[Ami GONE FROM CHROMIUM, 2014-01-27 20:27:55]

On Mon, Jan 27, 2014 at 12:09 PM, Antoine Labour <[email protected]> wrote:

> On Mon, Jan 27, 2014 at 11:10 AM, <[email protected]> wrote:
>
>> re: RenderViewObserver ... perhaps there's a yet-to-be-written frame-based
>> observer to support the out-of-process-frame work?
>
> RenderFrameObserver exists, if that's what could be applicable here.
>

HTML media elements (which roughly correspond 1:1 to WMPI/WMPA) need to be
reparentable, so I don't think tying to a frame is the right thing.
(unless "frame" in RFO means something other than iframe/windowframe)

To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].

[piman, 2014-01-27 20:36:08]

On Mon, Jan 27, 2014 at 12:27 PM, Ami Fischman <[email protected]>wrote:

> On Mon, Jan 27, 2014 at 12:09 PM, Antoine Labour <[email protected]>wrote:
>
>> On Mon, Jan 27, 2014 at 11:10 AM, <[email protected]> wrote:
>>
>>> re: RenderViewObserver ... perhaps there's a yet-to-be-written
>>> frame-based
>>> observer to support the out-of-process-frame work?
>>
>> RenderFrameObserver exists, if that's what could be applicable here.
>>
>
> HTML media elements (which roughly correspond 1:1 to WMPI/WMPA) need to be
> reparentable, so I don't think tying to a frame is the right thing.
> (unless "frame" in RFO means something other than iframe/windowframe)
>

I assume a RFO to the top-level frame would be kinda equivalent to the
existing RVO. But I don't know the exact semantics needed by the WMP*.

Antoine

To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].

[Ami GONE FROM CHROMIUM, 2014-01-27 21:03:46]

On Mon, Jan 27, 2014 at 12:35 PM, Antoine Labour <[email protected]> wrote:

> I assume a RFO to the top-level frame would be kinda equivalent to the
> existing RVO. But I don't know the exact semantics needed by the WMP*.


Yeah, me either.  acolwell@'s fixed a mess of reparenting-related bugs, so
filed 338481 <https://code.google.com/p/chromium/issues/detail?id=338481> &
assigned to him.

To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].

[jam, 2014-01-27 21:33:54]

On 2014/01/27 20:36:08, piman wrote:
> On Mon, Jan 27, 2014 at 12:27 PM, Ami Fischman <[email protected]>wrote:
> 
> > On Mon, Jan 27, 2014 at 12:09 PM, Antoine Labour <[email protected]>wrote:
> >
> >> On Mon, Jan 27, 2014 at 11:10 AM, <mailto:[email protected]> wrote:
> >>
> >>> re: RenderViewObserver ... perhaps there's a yet-to-be-written
> >>> frame-based
> >>> observer to support the out-of-process-frame work?
> >>
> >> RenderFrameObserver exists, if that's what could be applicable here.
> >>
> >
> > HTML media elements (which roughly correspond 1:1 to WMPI/WMPA) need to be
> > reparentable, so I don't think tying to a frame is the right thing.
> > (unless "frame" in RFO means something other than iframe/windowframe)
> >
> 
> I assume a RFO to the top-level frame would be kinda equivalent to the
> existing RVO. But I don't know the exact semantics needed by the WMP*.
> 
> Antoine

This class has a frame_ that is set on construction and never deleted. so using
a RenderFrameObserver that's tied to that WebFrame's RenderFrame lifetime seems
fine? i.e. RenderFrameObserver(RenderFrame::FromWebFrame(frame_))

[Ami GONE FROM CHROMIUM, 2014-01-27 21:45:31]

On Mon, Jan 27, 2014 at 1:33 PM, <[email protected]> wrote:

> This class has a frame_ that is set on construction and never deleted. so
> using
> a RenderFrameObserver that's tied to that WebFrame's RenderFrame lifetime
> seems
> fine? i.e. RenderFrameObserver(RenderFrame::FromWebFrame(frame_))
>

Yeah, either that or that's also a bug :(
Added to the bug.

To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].

[jam, 2014-01-27 22:48:06]

On 2014/01/27 21:45:31, Ami Fischman wrote:
> On Mon, Jan 27, 2014 at 1:33 PM, <mailto:[email protected]> wrote:
> 
> > This class has a frame_ that is set on construction and never deleted. so
> > using
> > a RenderFrameObserver that's tied to that WebFrame's RenderFrame lifetime
> > seems
> > fine? i.e. RenderFrameObserver(RenderFrame::FromWebFrame(frame_))
> >
> 
> Yeah, either that or that's also a bug :(
> Added to the bug.

This class, as written, assumes one RenderFrame (and corresponding WebFrame).
i.e. frame_ is used in many methods. I'm not sure why that's ok, and using
RenderFrameObserver is not.

[Ami GONE FROM CHROMIUM, 2014-01-27 22:56:08]

On Mon, Jan 27, 2014 at 2:48 PM, <[email protected]> wrote:

> This class, as written, assumes one RenderFrame (and corresponding
> WebFrame).
> i.e. frame_ is used in many methods. I'm not sure why that's ok, and using
> RenderFrameObserver is not.
>

Yeah, I'm not asserting that.
I agree with you that RFO is a fine choice iff the existing (re-)uses of
frame_ are fine.
I just don't know whether the latter is in fact the case, and hope
acolwell@can shed light on the situation in
crbug.com/338481.

To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].

[jam, 2014-01-27 23:32:10]

On 2014/01/27 22:56:08, Ami Fischman wrote:
> On Mon, Jan 27, 2014 at 2:48 PM, <mailto:[email protected]> wrote:
> 
> > This class, as written, assumes one RenderFrame (and corresponding
> > WebFrame).
> > i.e. frame_ is used in many methods. I'm not sure why that's ok, and using
> > RenderFrameObserver is not.
> >
> 
> Yeah, I'm not asserting that.
> I agree with you that RFO is a fine choice iff the existing (re-)uses of
> frame_ are fine.
> I just don't know whether the latter is in fact the case, and hope
> acolwell@can shed light on the situation in
> crbug.com/338481.

It seems that until that question is answered, using a RFO instead of a RVO is
fine.

[Ami GONE FROM CHROMIUM, 2014-01-29 18:35:58]

On 2014/01/27 23:32:10, jam wrote:
> On 2014/01/27 22:56:08, Ami Fischman wrote:
> > On Mon, Jan 27, 2014 at 2:48 PM, <mailto:[email protected]> wrote:
> > 
> > > This class, as written, assumes one RenderFrame (and corresponding
> > > WebFrame).
> > > i.e. frame_ is used in many methods. I'm not sure why that's ok, and using
> > > RenderFrameObserver is not.
> > >
> > 
> > Yeah, I'm not asserting that.
> > I agree with you that RFO is a fine choice iff the existing (re-)uses of
> > frame_ are fine.
> > I just don't know whether the latter is in fact the case, and hope
> > acolwell@can shed light on the situation in
> > crbug.com/338481.
> 
> It seems that until that question is answered, using a RFO instead of a RVO is
> fine.

\farnsworth
Aaron confirms I'm on crack and in fact all our reparenting fixes so far have
involved deleting/recreating WMPI/WMPA, so frame_ is not a bug, and RFO is a
reasonable thing to use.  Updated WMPI/WMPA & the CL description to match.

@jam / @scherkus: please re-review.

[scherkus (not reviewing), 2014-01-29 22:30:10]

lgtm

[jam, 2014-01-30 20:58:51]

lgtm

[commit-bot: I haz the power, 2014-01-30 23:41:17]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/137243005/100001

[commit-bot: I haz the power, 2014-01-31 00:57:38]

Retried try job too often on mac for step(s) compile
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac&number...

[commit-bot: I haz the power, 2014-01-31 00:57:48]

CQ bit was unchecked on CL. Ignoring.

[commit-bot: I haz the power, 2014-01-31 01:01:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/137243005/100001

[commit-bot: I haz the power, 2014-01-31 03:16:03]

Change committed as 248115

[commit-bot: I haz the power, 2014-01-31 03:16:10]

CQ bit was unchecked on CL. Ignoring.

[dglazkov, 2014-01-31 05:06:32]

It's very weird, but this I think had an effect on Blink layout tests. One
layout test is now failing across all bots:

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40...

[Ami GONE FROM CHROMIUM, 2014-01-31 06:24:23]

@dglazkov: thanks for reverting for me.

@jam/scherkus: please take a look at PS#4 which fixes the problem, and see below
for the reason for it.

@jln: please review the _messages change.

The test crashed because:
WebMediaPlayerImpl::~WebMediaPlayerImpl() (which runs after OnDestruct has
cleared WebMediaPlayerImpl::pipeline_) calls
RenderViewImpl::PlayerGone() calls
RenderViewImpl::DidPause() unnecessarily calls
WebMediaPlayerImpl::hasVideo() which blindly dereferences pipeline_
This wasn't a problem when WMPI was a RenderViewObserver (b/c ~WMPI would run
before the OnDestruct) but surfaced when I switched WMPI to being a
RenderFrameObserver.  This is easy to work around because
ViewHostMsg_MediaNotification doesn't actually need to convey has_{audio,video}
in the is_playing=false case.

Complete stacktrace for the curious is:
 ../../base/memory/scoped_ptr.h:376: element_type *scoped_ptr<media::Pipeline,
base::DefaultDeleter<media::Pipeline> >::operator->() const [U =
media::Pipeline, V = base::DefaultDeleter<media::Pipeline>]: Assertion
`impl_.get() != __null' failed.
Received signal 6
 [0x7ffff59037ee] base::debug::StackTrace::StackTrace()
 [0x7ffff5903327] base::debug::(anonymous namespace)::StackDumpSignalHandler()
 [0x7fffe8072cb0] <unknown>
 [0x7fffe7cd8425] gsignal
 [0x7fffe7cdbb8b] abort
 [0x7fffe7cd10ee] <unknown>
 [0x7fffe7cd1192] __assert_fail
 [0x7fffee0843c9] scoped_ptr<>::operator->()
 [0x7fffee07deb3] content::WebMediaPlayerImpl::hasVideo()
 [0x7fffee1e62c6] content::RenderViewImpl::DidPause()
 [0x7fffee1e6392] content::RenderViewImpl::PlayerGone()
 [0x7fffee1e63cf] content::RenderViewImpl::PlayerGone()
 [0x7fffee0799d7] content::WebMediaPlayerImpl::~WebMediaPlayerImpl()
 [0x7fffee079f89] content::WebMediaPlayerImpl::~WebMediaPlayerImpl()
 [0x7ffff11bf64e] WTF::OwnedPtrDeleter<>::deletePtr()
 [0x7ffff11be8f7] WTF::OwnPtr<>::clear()
 [0x7ffff11bb9e3] blink::WebMediaPlayerClientImpl::~WebMediaPlayerClientImpl()
 [0x7ffff11bbad9] blink::WebMediaPlayerClientImpl::~WebMediaPlayerClientImpl()
 [0x7ffff29a637e] WTF::OwnedPtrDeleter<>::deletePtr()
 [0x7ffff29a4427] WTF::OwnPtr<>::clear()
 [0x7ffff29931f0]
WebCore::HTMLMediaElement::clearMediaPlayerAndAudioSourceProviderClient()
 [0x7ffff2993981] WebCore::HTMLMediaElement::clearMediaPlayer()
 [0x7ffff299341a] WebCore::HTMLMediaElement::userCancelledLoad()
 [0x7ffff29a054a] WebCore::HTMLMediaElement::stop()
 [0x7ffff29a05ec] WebCore::HTMLMediaElement::stop()
 [0x7ffff2691da8]
WebCore::ContextLifecycleNotifier::notifyStoppingActiveDOMObjects()
 [0x7ffff277c3b1] WebCore::ExecutionContext::stopActiveDOMObjects()
 [0x7ffff26a8eed] WebCore::Document::detach()
 [0x7ffff26a92ec] WebCore::Document::prepareForDestruction()
 [0x7ffff2e40379] WebCore::Frame::setView()
 [0x7ffff2e41d01] WebCore::Frame::createView()
 [0x7ffff119159c] blink::WebFrameImpl::createFrameView()
 [0x7ffff11271b9]
blink::FrameLoaderClientImpl::transitionToCommittedForNewPage()
 [0x7ffff2fe3d94] WebCore::FrameLoader::commitProvisionalLoad()
 [0x7ffff2fd094c] WebCore::DocumentLoader::commitIfReady()
 [0x7ffff2fd2e94] WebCore::DocumentLoader::dataReceived()
 [0x7ffff2de0263] WebCore::RawResource::appendData()
 [0x7ffff2e08d3c] WebCore::ResourceLoader::didReceiveData()
 [0x7ffff494c17a] webkit_glue::WebURLLoaderImpl::Context::OnReceivedData()
 [0x7ffff494a691] webkit_glue::WebURLLoaderImpl::Context::HandleDataURL()
 [0x7ffff494f9f2] base::internal::RunnableAdapter<>::Run()
 [0x7ffff494f969] base::internal::InvokeHelper<>::MakeItSo()
 [0x7ffff494f925] base::internal::Invoker<>::Run()
 [0x7ffff58ec6ae] base::Callback<>::Run()
 [0x7ffff59ab263] base::MessageLoop::RunTask()
 [0x7ffff59ab57b] base::MessageLoop::DeferOrRunPendingTask()
 [0x7ffff59ab7a5] base::MessageLoop::DoWork()
 [0x7ffff59bc828] base::MessagePumpDefault::Run()
 [0x7ffff59aac07] base::MessageLoop::RunHandler()
 [0x7ffff5a1f812] base::RunLoop::Run()
 [0x7ffff59aa431] base::MessageLoop::Run()
 [0x7fffee23ce7c] content::RendererMain()
 [0x7fffed3112a7] content::RunZygote()
 [0x7fffed3115a9] content::RunNamedProcessTypeMain()
 [0x7fffed31411d] content::ContentMainRunnerImpl::Run()
 [0x7fffed310ab4] content::ContentMain()
 [0x0000004412f5] main
 [0x7fffe7cc376d] __libc_start_main

[jam, 2014-01-31 17:40:47]

lgtm

[scherkus (not reviewing), 2014-01-31 20:51:08]

lgtm

[Ami GONE FROM CHROMIUM, 2014-01-31 21:01:49]

-jln (OOO), +cevans for _messages.h please

[Chris Evans, 2014-01-31 21:15:30]

On 2014/01/31 21:01:49, Ami Fischman wrote:
> -jln (OOO), +cevans for _messages.h please

lgtm

[Ami GONE FROM CHROMIUM, 2014-01-31 21:16:28]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2014-01-31 21:24:46]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/137243005/120001

[commit-bot: I haz the power, 2014-01-31 22:07:37]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2014-01-31 22:07:37]

Retried try job too often on linux_aura for step(s) app_list_unittests,
aura_unittests, browser_tests, compositor_unittests, content_browsertests,
content_unittests, events_unittests, interactive_ui_tests, unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_aura...

[commit-bot: I haz the power, 2014-01-31 22:07:38]

CQ bit was unchecked on CL. Ignoring.

[commit-bot: I haz the power, 2014-01-31 22:07:43]

CQ bit was unchecked on CL. Ignoring.

[Ami GONE FROM CHROMIUM, 2014-01-31 22:57:25]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2014-01-31 22:58:51]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/137243005/120001

[commit-bot: I haz the power, 2014-01-31 23:30:19]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2014-01-31 23:30:21]

Retried try job too often on linux_aura for step(s) app_list_unittests,
aura_unittests, browser_tests, compositor_unittests, content_browsertests,
content_unittests, events_unittests, interactive_ui_tests, unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_aura...

[commit-bot: I haz the power, 2014-01-31 23:30:22]

CQ bit was unchecked on CL. Ignoring.

[commit-bot: I haz the power, 2014-01-31 23:30:22]

CQ bit was unchecked on CL. Ignoring.

[Ami GONE FROM CHROMIUM, 2014-01-31 23:59:16]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2014-01-31 23:59:49]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/137243005/120001

[commit-bot: I haz the power, 2014-02-01 00:31:01]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2014-02-01 00:31:02]

Retried try job too often on linux_aura for step(s) app_list_unittests,
aura_unittests, browser_tests, compositor_unittests, content_browsertests,
content_unittests, events_unittests, interactive_ui_tests, unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_aura...

[commit-bot: I haz the power, 2014-02-01 00:31:06]

CQ bit was unchecked on CL. Ignoring.

[commit-bot: I haz the power, 2014-02-01 00:31:12]

CQ bit was unchecked on CL. Ignoring.

[Ami GONE FROM CHROMIUM, 2014-02-01 01:16:33]

Committed patchset #4 manually as r248321 (presubmit successful).

[jln (very slow on Chromium), 2014-02-03 21:33:28]

If a compromised process sends MediaPausedNotification twice, you'll delete
NULL.

It's not a security vulnerability, but it's not a generally safe code construct.

https://codereview.chromium.org/137243005/diff/120001/content/browser/web_con...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/137243005/diff/120001/content/browser/web_con...
content/browser/web_contents/web_contents_impl.cc:2436: delete
power_save_blockers_[render_view_message_source_][player_cookie];
Shouldn't PowerSaveBlockerMap be a map to a map to scoped_ptr<>?

[Ami GONE FROM CHROMIUM, 2014-02-03 21:42:46]

On Mon, Feb 3, 2014 at 1:33 PM, <[email protected]> wrote:

> If a compromised process sends MediaPausedNotification twice, you'll
> delete NULL.
> It's not a security vulnerability, but it's not a generally safe code
> construct.
>

delete NULL;
is a no-op in the language spec (5.3.5 - Delete [expr.delete] says: "if the
value of the operand of delete is the null pointer the operation has no
effect.").  In what sense is it not a "safe code construct"?

https://codereview.chromium.org/137243005/diff/120001/
> content/browser/web_contents/web_contents_impl.cc
> File content/browser/web_contents/web_contents_impl.cc (right):
>
> https://codereview.chromium.org/137243005/diff/120001/
> content/browser/web_contents/web_contents_impl.cc#newcode2436
> content/browser/web_contents/web_contents_impl.cc:2436: delete
> power_save_blockers_[render_view_message_source_][player_cookie];
> Shouldn't PowerSaveBlockerMap be a map to a map to scoped_ptr<>?
>

scoped_ptr<>s can't be put in STL containers (b/c before we adopt C++11
they don't have STL-compatible move semantics).
It /could/ hold linked_ptrs, instead.


> https://codereview.chromium.org/137243005/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].

[jln (very slow on Chromium), 2014-02-03 22:17:05]

On 2014/02/03 21:42:46, Ami Fischman wrote:

> delete NULL;
> is a no-op in the language spec (5.3.5 - Delete [expr.delete] says: "if the
> value of the operand of delete is the null pointer the operation has no
> effect.").  In what sense is it not a "safe code construct"?

It's not a safe code construct because it can easily confuse readers that the
object is not deleted yet and lead to UAF.
Adding "CHECK(blah->IsFoo());" before "delete blah" is a common mistake to make.
However, on most platforms it's not exploitable anymore (most memory allocators
won't
allocate the first page).

if (X) {} is generally better than doing safe no-op operations on NULL pointers.

> > Shouldn't PowerSaveBlockerMap be a map to a map to scoped_ptr<>?
> >
> 
> scoped_ptr<>s can't be put in STL containers (b/c before we adopt C++11
> they don't have STL-compatible move semantics).
> It /could/ hold linked_ptrs, instead.

Ohh yeah, right!