OOPIF: Specify previous sibling frames when creating new RenderFrames.

OOPIF: Specify previous sibling frames when creating RenderFrames.

When initializing a new renderer for an OOP frame, the current
behavior is to first create all the RenderFrameProxies, and then to
create the new RenderFrame, appending it as its parent's last child in
the frame tree.  This disregards the order of sibling frames and thus
may break indexed window access (e.g., window.frames[2]).

This CL passes the previous sibling's routing ID in the
FrameMsg_NewFrame message, so that the new frame can be inserted in
the correct place in the frame tree.  Note that we don't need to do
this for RenderFrameProxies, as those are already created in the
correct order (by CreateProxiesForSiteInstance) when initializing a
new renderer process.

Corresponding Blink CL: https://codereview.chromium.org/1119823003/

BUG=478792
Committed: https://crrev.com/134cdb8c234847ebde156e46cad95be3221dc66b
Cr-Commit-Position: refs/heads/master@{#328384}

[alexmos, 2015-05-01 22:32:48]

alexmos@chromium.org changed reviewers:
+ nasko@chromium.org

[alexmos, 2015-05-01 22:32:49]

Nasko, can you please review this CL for fixing the indexed frame access?  This
also has a Blink side (https://codereview.chromium.org/1119823003/) that will
need to land first.

[nasko, 2015-05-04 17:16:56]

Great start! A few comments, though mostly nits.

https://codereview.chromium.org/1113393004/diff/40001/content/browser/frame_h...
File content/browser/frame_host/render_frame_host_manager.cc (right):

https://codereview.chromium.org/1113393004/diff/40001/content/browser/frame_h...
content/browser/frame_host/render_frame_host_manager.cc:1663: // At point, all
RenderFrameProxies for sibling frames have already been
nit: "At point" - did you mean "At this point"?

https://codereview.chromium.org/1113393004/diff/40001/content/browser/frame_h...
content/browser/frame_host/render_frame_host_manager.cc:1668: if (FrameTreeNode*
previous_sibling = frame_tree_node_->PreviousSibling()) {
nit: Please separate the variable from the if statement.

https://codereview.chromium.org/1113393004/diff/40001/content/browser/site_pe...
File content/browser/site_per_process_browsertest.cc (right):

https://codereview.chromium.org/1113393004/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:885:
PostMessageAndWaitForReply(root->child_at(1),
I like the simplification of this helper function!

https://codereview.chromium.org/1113393004/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:2168:
EXPECT_TRUE(WaitForRenderFrameReady(child0->current_frame_host()));
Do we really need those WaitForRenderFrameReady calls?

https://codereview.chromium.org/1113393004/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:2192: success = false;
nit: Let's put an empty line before this line to help separate the different
tests we are performing.
Alternative, instead of resetting success each time, wrap each test in a {} code
block.

https://codereview.chromium.org/1113393004/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:2224:
EXPECT_TRUE(ExecuteScriptAndExtractInt(
nit: Having empty lines here too will make it a tad bit more readable since
these are different frames expectations.

https://codereview.chromium.org/1113393004/diff/40001/content/common/frame_me...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/1113393004/diff/40001/content/common/frame_me...
content/common/frame_messages.h:325:
IPC_STRUCT_MEMBER(FrameMsg_NewFrame_WidgetParams, widget_params)
nit: Let's add a comment about what widget_params means. This way it is
consistent with the rest of the fields of this struct.

https://codereview.chromium.org/1113393004/diff/40001/content/common/frame_me...
content/common/frame_messages.h:420: IPC_MESSAGE_CONTROL1(FrameMsg_NewFrame,
FrameMsg_NewFrame_Params);
nit: /* params */

https://codereview.chromium.org/1113393004/diff/40001/content/renderer/render...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/1113393004/diff/40001/content/renderer/render...
content/renderer/render_frame_impl.cc:587: blink::WebFrame*
previous_sibling_web_frame = nullptr;
Wouldn't RFP::FromRoutingID return nullptr if not found?

https://codereview.chromium.org/1113393004/diff/40001/content/renderer/render...
content/renderer/render_frame_impl.cc:589:
RenderFrameProxy::FromRoutingID(previous_sibling_routing_id)) {
nit: Separate the variable declaration and function call into a separate line
from the if statement testing the condition of the variable.

https://codereview.chromium.org/1113393004/diff/40001/content/renderer/render...
content/renderer/render_frame_impl.cc:592: 
nit: What about (D)CHECKing the condition of MSG_ROUTING_NONE means no other
child frames exist in the parent frame?

[alexmos, 2015-05-04 21:18:04]

https://codereview.chromium.org/1113393004/diff/40001/content/browser/frame_h...
File content/browser/frame_host/render_frame_host_manager.cc (right):

https://codereview.chromium.org/1113393004/diff/40001/content/browser/frame_h...
content/browser/frame_host/render_frame_host_manager.cc:1663: // At point, all
RenderFrameProxies for sibling frames have already been
On 2015/05/04 17:16:55, nasko wrote:
> nit: "At point" - did you mean "At this point"?

Indeed.  Thanks for catching!

https://codereview.chromium.org/1113393004/diff/40001/content/browser/frame_h...
content/browser/frame_host/render_frame_host_manager.cc:1668: if (FrameTreeNode*
previous_sibling = frame_tree_node_->PreviousSibling()) {
On 2015/05/04 17:16:55, nasko wrote:
> nit: Please separate the variable from the if statement.

Done.  Apparently, the style guide was recently updated to encourage the former
pattern, but I still changed this one to match the patterns in this file (like
the existing_proxy right below).

https://codereview.chromium.org/1113393004/diff/40001/content/browser/site_pe...
File content/browser/site_per_process_browsertest.cc (right):

https://codereview.chromium.org/1113393004/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:2168:
EXPECT_TRUE(WaitForRenderFrameReady(child0->current_frame_host()));
On 2015/05/04 17:16:55, nasko wrote:
> Do we really need those WaitForRenderFrameReady calls?

They won't be necessary once we switch TestFrameNavigationObserver to wait for
DidFinishLoad, but before that, I'm actually not sure.  I recently ran into
NavigateFrameToURL not waiting for postMessage scripts to be loaded in a similar
test.  Here, the test seems to work without these calls (I'm guessing the
"window === parent.frames[x]" executions give postMessage scripts enough time to
load -- commenting those out makes the test fail), but I'm concerned that it may
actually be flaky without them.

https://codereview.chromium.org/1113393004/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:2192: success = false;
On 2015/05/04 17:16:55, nasko wrote:
> nit: Let's put an empty line before this line to help separate the different
> tests we are performing.

Done.

> Alternative, instead of resetting success each time, wrap each test in a {}
code
> block.

I've tried this but ended up keeping the blocks without the {}, since it looked
a bit cleaner and more compact, but I'm happy to change it. :)

https://codereview.chromium.org/1113393004/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:2224:
EXPECT_TRUE(ExecuteScriptAndExtractInt(
On 2015/05/04 17:16:55, nasko wrote:
> nit: Having empty lines here too will make it a tad bit more readable since
> these are different frames expectations.

Done.

https://codereview.chromium.org/1113393004/diff/40001/content/common/frame_me...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/1113393004/diff/40001/content/common/frame_me...
content/common/frame_messages.h:325:
IPC_STRUCT_MEMBER(FrameMsg_NewFrame_WidgetParams, widget_params)
On 2015/05/04 17:16:56, nasko wrote:
> nit: Let's add a comment about what widget_params means. This way it is
> consistent with the rest of the fields of this struct.

Done.

https://codereview.chromium.org/1113393004/diff/40001/content/common/frame_me...
content/common/frame_messages.h:420: IPC_MESSAGE_CONTROL1(FrameMsg_NewFrame,
FrameMsg_NewFrame_Params);
On 2015/05/04 17:16:56, nasko wrote:
> nit: /* params */

Done.

https://codereview.chromium.org/1113393004/diff/40001/content/renderer/render...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/1113393004/diff/40001/content/renderer/render...
content/renderer/render_frame_impl.cc:587: blink::WebFrame*
previous_sibling_web_frame = nullptr;
On 2015/05/04 17:16:56, nasko wrote:
> Wouldn't RFP::FromRoutingID return nullptr if not found?

It will, but that ends up in the previous_sibling_proxy, and we still need to
ensure the web_frame also ends up with nullptr in that case, right?

https://codereview.chromium.org/1113393004/diff/40001/content/renderer/render...
content/renderer/render_frame_impl.cc:589:
RenderFrameProxy::FromRoutingID(previous_sibling_routing_id)) {
On 2015/05/04 17:16:56, nasko wrote:
> nit: Separate the variable declaration and function call into a separate line
> from the if statement testing the condition of the variable.

Done.

https://codereview.chromium.org/1113393004/diff/40001/content/renderer/render...
content/renderer/render_frame_impl.cc:592: 
On 2015/05/04 17:16:56, nasko wrote:
> nit: What about (D)CHECKing the condition of MSG_ROUTING_NONE means no other
> child frames exist in the parent frame?

That's not necessarily the case, I think -- there could be other children, and
the NONE just means that the new frame should be inserted before all of them as
the leftmost child.

[nasko, 2015-05-04 22:02:13]

LGTM, provided you fix some of the wording on the IPC struct.

https://codereview.chromium.org/1113393004/diff/40001/content/browser/site_pe...
File content/browser/site_per_process_browsertest.cc (right):

https://codereview.chromium.org/1113393004/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:2168:
EXPECT_TRUE(WaitForRenderFrameReady(child0->current_frame_host()));
On 2015/05/04 21:18:03, alexmos wrote:
> On 2015/05/04 17:16:55, nasko wrote:
> > Do we really need those WaitForRenderFrameReady calls?
> 
> They won't be necessary once we switch TestFrameNavigationObserver to wait for
> DidFinishLoad, but before that, I'm actually not sure.  I recently ran into
> NavigateFrameToURL not waiting for postMessage scripts to be loaded in a
similar
> test.  Here, the test seems to work without these calls (I'm guessing the
> "window === parent.frames[x]" executions give postMessage scripts enough time
to
> load -- commenting those out makes the test fail), but I'm concerned that it
may
> actually be flaky without them.

Let's at least add a TODO to remove them once we fix
TestFrameNavigationObserver.

https://codereview.chromium.org/1113393004/diff/40001/content/renderer/render...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/1113393004/diff/40001/content/renderer/render...
content/renderer/render_frame_impl.cc:587: blink::WebFrame*
previous_sibling_web_frame = nullptr;
On 2015/05/04 21:18:04, alexmos wrote:
> On 2015/05/04 17:16:56, nasko wrote:
> > Wouldn't RFP::FromRoutingID return nullptr if not found?
> 
> It will, but that ends up in the previous_sibling_proxy, and we still need to
> ensure the web_frame also ends up with nullptr in that case, right?

Acknowledged.

https://codereview.chromium.org/1113393004/diff/40001/content/renderer/render...
content/renderer/render_frame_impl.cc:592: 
On 2015/05/04 21:18:04, alexmos wrote:
> On 2015/05/04 17:16:56, nasko wrote:
> > nit: What about (D)CHECKing the condition of MSG_ROUTING_NONE means no other
> > child frames exist in the parent frame?
> 
> That's not necessarily the case, I think -- there could be other children, and
> the NONE just means that the new frame should be inserted before all of them
as
> the leftmost child.

Acknowledged.

https://codereview.chromium.org/1113393004/diff/60001/content/common/frame_me...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/1113393004/diff/60001/content/common/frame_me...
content/common/frame_messages.h:312: // MSG_ROUTING_NONE, the frame will be
created as the first child of its
nit: Let's change the wording a bit, as it might be a bit confusing. "first
child" can be read as the "first child to be inserted in the children list of a
parent node". In your other reply, you worded it as "the leftmost child". Since
it is the latter, it can be better worded.

[alexmos, 2015-05-04 22:12:01]

https://codereview.chromium.org/1113393004/diff/40001/content/browser/site_pe...
File content/browser/site_per_process_browsertest.cc (right):

https://codereview.chromium.org/1113393004/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:2168:
EXPECT_TRUE(WaitForRenderFrameReady(child0->current_frame_host()));
On 2015/05/04 22:02:13, nasko wrote:
> On 2015/05/04 21:18:03, alexmos wrote:
> > On 2015/05/04 17:16:55, nasko wrote:
> > > Do we really need those WaitForRenderFrameReady calls?
> > 
> > They won't be necessary once we switch TestFrameNavigationObserver to wait
for
> > DidFinishLoad, but before that, I'm actually not sure.  I recently ran into
> > NavigateFrameToURL not waiting for postMessage scripts to be loaded in a
> similar
> > test.  Here, the test seems to work without these calls (I'm guessing the
> > "window === parent.frames[x]" executions give postMessage scripts enough
time
> to
> > load -- commenting those out makes the test fail), but I'm concerned that it
> may
> > actually be flaky without them.
> 
> Let's at least add a TODO to remove them once we fix
> TestFrameNavigationObserver.

Good idea, done here and in the one other test where I used this.

https://codereview.chromium.org/1113393004/diff/60001/content/common/frame_me...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/1113393004/diff/60001/content/common/frame_me...
content/common/frame_messages.h:312: // MSG_ROUTING_NONE, the frame will be
created as the first child of its
On 2015/05/04 22:02:13, nasko wrote:
> nit: Let's change the wording a bit, as it might be a bit confusing. "first
> child" can be read as the "first child to be inserted in the children list of
a
> parent node". In your other reply, you worded it as "the leftmost child".
Since
> it is the latter, it can be better worded.

Done.

[alexmos, 2015-05-05 17:59:10]

The CQ bit was checked by alexmos@chromium.org to run a CQ dry run

[alexmos, 2015-05-05 17:59:10]

The patchset sent to the CQ was uploaded after l-g-t-m from nasko@chromium.org
Link to the patchset: https://codereview.chromium.org/1113393004/#ps80001
(title: "Add TODOs and fix comment")

[commit-bot: I haz the power, 2015-05-05 18:00:04]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1113393004/80001

[commit-bot: I haz the power, 2015-05-05 19:26:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-05-05 19:26:12]

Dry run: This issue passed the CQ dry run.

[alexmos, 2015-05-05 19:44:11]

The CQ bit was checked by alexmos@chromium.org

[commit-bot: I haz the power, 2015-05-05 19:44:39]

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

[commit-bot: I haz the power, 2015-05-05 19:50:42]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2015-05-05 19:51:39]

Patchset 5 (id:??) landed as
https://crrev.com/134cdb8c234847ebde156e46cad95be3221dc66b
Cr-Commit-Position: refs/heads/master@{#328384}

[piman, 2015-05-05 22:28:23]

A revert of this CL (patchset #5 id:80001) has been created in
https://codereview.chromium.org/1118083004/ by piman@chromium.org.

The reason for reverting is: Causing failures on asan bots:
https://build.chromium.org/p/chromium.memory/builders/Linux%20ASan%20LSan%20T...
https://build.chromium.org/p/chromium.memory/builders/Linux%20Chromium%20OS%2....

[dcheng, 2015-05-05 22:35:10]

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

[dcheng, 2015-05-05 22:35:11]

The "leak" appears to be another case of symbolization not always being
reliable. The leaking stack is:


==22350==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 64 byte(s) in 1 object(s) allocated from:
    #0 0x4dc86b in __interceptor_malloc
(/tmp/run_tha_testoNK3I1/out/Release/content_browsertests+0x4dc86b)
    #1 0x3d5d120 in partitionAllocGenericFlags
third_party/WebKit/Source/wtf/PartitionAlloc.h:569:20
    #2 0x3d5d120 in partitionAllocGeneric
third_party/WebKit/Source/wtf/PartitionAlloc.h:585
    #3 0x3d5d120 in WTF::fastMalloc(unsigned long)
third_party/WebKit/Source/wtf/FastMalloc.cpp:56
    #4 0x77ef527 in operator new
third_party/WebKit/Source/wtf/RefCounted.h:166:5
    #5 0x77ef527 in blink::ScriptState::create(v8::Local<v8::Context>,
WTF::PassRefPtr<blink::DOMWrapperWorld>)
third_party/WebKit/Source/bindings/core/v8/ScriptState.cpp:17
    #6 0x7877626 in blink::WindowProxy::createContext()
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:303:21
    #7 0x78760e6 in blink::WindowProxy::initialize()
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:223:5
    #8 0x7875c74 in initializeIfNeeded
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:209:19
    #9 0x7875c74 in blink::WindowProxy::takeGlobalFrom(blink::WindowProxy*)
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:165
    #10 0x787cf70 in
blink::WindowProxyManager::takeGlobalFrom(blink::WindowProxyManager*)
third_party/WebKit/Source/bindings/core/v8/WindowProxyManager.cpp:88:5
    #11 0x4dd87c8 in blink::WebFrame::swap(blink::WebFrame*)
third_party/WebKit/Source/web/WebFrame.cpp:106:5
    #12 0xd9aff6 in content::RenderFrameImpl::OnSwapOut(int, bool,
content::FrameReplicationState const&)
content/renderer/render_frame_impl.cc:1224:7
    #13 0xa18bb1 in content::RenderFrameImplTest::SetUp()
content/renderer/render_frame_impl_browsertest.cc:49:5
    #14 0x17a3fb3 in HandleExceptionsInMethodIfSupported<testing::Test, void>
testing/gtest/src/gtest.cc:2420:12
    #15 0x17a3fb3 in testing::Test::Run() testing/gtest/src/gtest.cc:2432
    #16 0x17a615d in testing::TestInfo::Run() testing/gtest/src/gtest.cc:2612:5
    #17 0x17a6eda in testing::TestCase::Run() testing/gtest/src/gtest.cc:2730:5
    #18 0x17bad33 in testing::internal::UnitTestImpl::RunAllTests()
testing/gtest/src/gtest.cc:4602:11
    #19 0x17ba38b in
HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>
testing/gtest/src/gtest.cc:2420:12
    #20 0x17ba38b in testing::UnitTest::Run() testing/gtest/src/gtest.cc:4220
    #21 0x1423dea in RUN_ALL_TESTS testing/gtest/include/gtest/gtest.h:2326:10
    #22 0x1423dea in base::TestSuite::Run() base/test/test_suite.cc:228
    #23 0x1232ed5 in content::ContentTestLauncherDelegate::RunTestSuite(int,
char**) content/test/content_test_launcher.cc:102:12
    #24 0x13d91b6 in content::LaunchTests(content::TestLauncherDelegate*, int,
int, char**) content/public/test/test_launcher.cc:475:12
    #25 0x1232dab in main content/test/content_test_launcher.cc:129:10
    #26 0x7f11f178676c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226

We have a leak suppression for blink::WindowProxy::initializeIfNeeded... but
stack #8 is symbolized to initializeIfNeeded.

[dcheng, 2015-05-05 22:36:03]

On 2015/05/05 at 22:35:11, dcheng wrote:
> The "leak" appears to be another case of symbolization not always being
reliable. The leaking stack is:
> 
> 
> ==22350==ERROR: LeakSanitizer: detected memory leaks
> 
> Direct leak of 64 byte(s) in 1 object(s) allocated from:
>     #0 0x4dc86b in __interceptor_malloc
(/tmp/run_tha_testoNK3I1/out/Release/content_browsertests+0x4dc86b)
>     #1 0x3d5d120 in partitionAllocGenericFlags
third_party/WebKit/Source/wtf/PartitionAlloc.h:569:20
>     #2 0x3d5d120 in partitionAllocGeneric
third_party/WebKit/Source/wtf/PartitionAlloc.h:585
>     #3 0x3d5d120 in WTF::fastMalloc(unsigned long)
third_party/WebKit/Source/wtf/FastMalloc.cpp:56
>     #4 0x77ef527 in operator new
third_party/WebKit/Source/wtf/RefCounted.h:166:5
>     #5 0x77ef527 in blink::ScriptState::create(v8::Local<v8::Context>,
WTF::PassRefPtr<blink::DOMWrapperWorld>)
third_party/WebKit/Source/bindings/core/v8/ScriptState.cpp:17
>     #6 0x7877626 in blink::WindowProxy::createContext()
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:303:21
>     #7 0x78760e6 in blink::WindowProxy::initialize()
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:223:5
>     #8 0x7875c74 in initializeIfNeeded
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:209:19
>     #9 0x7875c74 in blink::WindowProxy::takeGlobalFrom(blink::WindowProxy*)
third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp:165
>     #10 0x787cf70 in
blink::WindowProxyManager::takeGlobalFrom(blink::WindowProxyManager*)
third_party/WebKit/Source/bindings/core/v8/WindowProxyManager.cpp:88:5
>     #11 0x4dd87c8 in blink::WebFrame::swap(blink::WebFrame*)
third_party/WebKit/Source/web/WebFrame.cpp:106:5
>     #12 0xd9aff6 in content::RenderFrameImpl::OnSwapOut(int, bool,
content::FrameReplicationState const&)
content/renderer/render_frame_impl.cc:1224:7
>     #13 0xa18bb1 in content::RenderFrameImplTest::SetUp()
content/renderer/render_frame_impl_browsertest.cc:49:5
>     #14 0x17a3fb3 in HandleExceptionsInMethodIfSupported<testing::Test, void>
testing/gtest/src/gtest.cc:2420:12
>     #15 0x17a3fb3 in testing::Test::Run() testing/gtest/src/gtest.cc:2432
>     #16 0x17a615d in testing::TestInfo::Run()
testing/gtest/src/gtest.cc:2612:5
>     #17 0x17a6eda in testing::TestCase::Run()
testing/gtest/src/gtest.cc:2730:5
>     #18 0x17bad33 in testing::internal::UnitTestImpl::RunAllTests()
testing/gtest/src/gtest.cc:4602:11
>     #19 0x17ba38b in
HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>
testing/gtest/src/gtest.cc:2420:12
>     #20 0x17ba38b in testing::UnitTest::Run() testing/gtest/src/gtest.cc:4220
>     #21 0x1423dea in RUN_ALL_TESTS testing/gtest/include/gtest/gtest.h:2326:10
>     #22 0x1423dea in base::TestSuite::Run() base/test/test_suite.cc:228
>     #23 0x1232ed5 in content::ContentTestLauncherDelegate::RunTestSuite(int,
char**) content/test/content_test_launcher.cc:102:12
>     #24 0x13d91b6 in content::LaunchTests(content::TestLauncherDelegate*, int,
int, char**) content/public/test/test_launcher.cc:475:12
>     #25 0x1232dab in main content/test/content_test_launcher.cc:129:10
>     #26 0x7f11f178676c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
> 
> We have a leak suppression for blink::WindowProxy::initializeIfNeeded... but
stack #8 is symbolized to initializeIfNeeded.

I've already filed a bug for the symbolization issue: https://crbug.com/484760.
In the meantime, we'll need to check in a broader suppression though =(