Fetch DataConsumerHandle test cleanup

Fetch DataConsumerHandle test cleanup

This CL is a preperation for decoupling Updater from
CompositingDataConsumerHandle. This CL does:

 - Move TestingThread from TeeTest.cpp to TestUtil.h and use it in
   ThreadingTestBase to support oilpan objects in created threads.
 - Move CompositingDataConsumerHandle creation from the main thread
   to the updating thread. Creating the handle in the main thread
   violates the handle assumption.

BUG=480746
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=197743

[yhirano, 2015-06-19 10:07:48]

yhirano@chromium.org changed reviewers:
+ hiroshige@chromium.org

[yhirano, 2015-06-19 10:07:49]

No hurry. This CL depends on https://codereview.chromium.org/1195563002/.

[hiroshige, 2015-06-22 19:24:49]

Basically good, but I'm not sure about initialization/shutdown of
DataConsumerHandleTestUtil::TestingThread::m_isolate.

nit optional: "TestingThread" sounds like "reading/updatingThread". Another name
might be better (TestingThread is acceptable though).

[yhirano, 2015-06-23 05:34:33]

> nit optional: "TestingThread" sounds like "reading/updatingThread". Another
name
> might be better (TestingThread is acceptable though).
As it is in DataConsumerHandleTestUtil, just Thread may be good. What do you
think?

[hiroshige, 2015-06-23 06:18:19]

On 2015/06/23 05:34:33, yhirano wrote:
> > nit optional: "TestingThread" sounds like "reading/updatingThread". Another
> name
> > might be better (TestingThread is acceptable though).
> As it is in DataConsumerHandleTestUtil, just Thread may be good. What do you
> think?

Looks good.

[yhirano, 2015-06-23 07:51:02]

On 2015/06/23 06:18:19, hiroshige wrote:
> On 2015/06/23 05:34:33, yhirano wrote:
> > > nit optional: "TestingThread" sounds like "reading/updatingThread".
Another
> > name
> > > might be better (TestingThread is acceptable though).
> > As it is in DataConsumerHandleTestUtil, just Thread may be good. What do you
> > think?
> 
> Looks good.

Done.

[hiroshige, 2015-06-23 09:53:10]

lgtm.

[yhirano, 2015-06-24 13:58:27]

The CQ bit was checked by yhirano@chromium.org

[yhirano, 2015-06-24 13:58:29]

The patchset sent to the CQ was uploaded after l-g-t-m from
hiroshige@chromium.org
Link to the patchset: https://codereview.chromium.org/1198443002/#ps40001
(title: "rebase")

[commit-bot: I haz the power, 2015-06-24 13:58:39]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1198443002/40001

[commit-bot: I haz the power, 2015-06-24 15:08:59]

Committed patchset #3 (id:40001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=197743

[Nico, 2015-08-26 03:54:51]

thakis@chromium.org changed reviewers:
+ thakis@chromium.org

[Nico, 2015-08-26 03:54:52]

https://codereview.chromium.org/1198443002/diff/40001/Source/modules/fetch/Da...
File Source/modules/fetch/DataConsumerHandleTestUtil.cpp (right):

https://codereview.chromium.org/1198443002/diff/40001/Source/modules/fetch/Da...
Source/modules/fetch/DataConsumerHandleTestUtil.cpp:36: m_scriptState =
ScriptState::create(v8::Context::New(isolate()),
DOMWrapperWorld::create(isolate()));
It looks like this is leaked somehow, see e.g.
http://build.chromium.org/p/chromium.fyi/builders/ClangToTLinuxASan%20tester/...
:

Direct leak of 64 byte(s) in 1 object(s) allocated from:
    #0 0x585328 in __interceptor_malloc
/b/build/slave/ClangToTLinuxASan/build/src/third_party/llvm/compiler-rt/lib/asan/asan_malloc_linux.cc:40
    #1 0x1d8bc30 in partitionAllocGenericFlags
third_party/WebKit/Source/wtf/PartitionAlloc.h:691:20
    #2 0x1d8bc30 in partitionAllocGeneric
third_party/WebKit/Source/wtf/PartitionAlloc.h:707
    #3 0x1d8bc30 in WTF::fastMalloc(unsigned long)
third_party/WebKit/Source/wtf/FastMalloc.cpp:56
    #4 0x6ad1b04 in operator new
third_party/WebKit/Source/wtf/RefCounted.h:166:5
    #5 0x6ad1b04 in blink::ScriptState::create(v8::Local\u003Cv8::Context>,
WTF::PassRefPtr\u003Cblink::DOMWrapperWorld>)
third_party/WebKit/Source/bindings/core/v8/ScriptState.cpp:17
    #6 0xfc1b17 in blink::DataConsumerHandleTestUtil::Thread::initialize()
third_party/WebKit/Source/modules/fetch/DataConsumerHandleTestUtil.cpp:36:25
    #7 0x8e44c21 in Run base/bind_internal.h:157:12
    #8 0x8e44c21 in MakeItSo base/bind_internal.h:293
    #9 0x8e44c21 in base::internal::Invoker\u003Cbase::IndexSequence\u003C0ul>,
base::internal::BindState\u003Cbase::internal::RunnableAdapter\u003Cvoid
(*)(scoped_ptr\u003Cblink::WebThread::Task,
base::DefaultDeleter\u003Cblink::WebThread::Task> >)>, void
(scoped_ptr\u003Cblink::WebThread::Task,
base::DefaultDeleter\u003Cblink::WebThread::Task> >),
base::internal::TypeList\u003Cbase::internal::PassedWrapper\u003Cscoped_ptr\u003Cblink::WebThread::Task,
base::DefaultDeleter\u003Cblink::WebThread::Task> > > > >,
base::internal::TypeList\u003Cbase::internal::UnwrapTraits\u003Cbase::internal::PassedWrapper\u003Cscoped_ptr\u003Cblink::WebThread::Task,
base::DefaultDeleter\u003Cblink::WebThread::Task> > > > >,
base::internal::InvokeHelper\u003Cfalse, void,
base::internal::RunnableAdapter\u003Cvoid
(*)(scoped_ptr\u003Cblink::WebThread::Task,
base::DefaultDeleter\u003Cblink::WebThread::Task> >)>,
base::internal::TypeList\u003Cscoped_ptr\u003Cblink::WebThread::Task,
base::DefaultDeleter\u003Cblink::WebThread::Task> > > >, void
()>::Run(base::internal::BindStateBase*) base/bind_internal.h:343
    #10 0x193d5a4 in Run base/callback.h:396:12


Do you have an idea how this could happen?

[yhirano, 2015-08-26 04:49:17]

Thanks for reporting. I filed a bug (https://crbug.com/524875).