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

Issue 678624 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

mojo::edk::Init() sometimes called twice or more.

Project Member Reported by hidehiko@chromium.org, Jan 5 2017

Issue description

Chrome Version: ToT
OS: Any

While fixing  crbug.com/672385 , I though it would be nice to add DCHECK to mojo::edk::Init() so that we can trap the linked bug case earlier.

https://codereview.chromium.org/2617713002/
is the trial CL, but there are more failing tests.

Some are testing code problem like  crbug.com/672385 , but some others look more complicated, e.g., NaCl/PPAPI tests.
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_rel_ng/builds/342648/steps/browser_tests%20%28with%20patch%29/logs/stdio

Yuzhu, are these actually unexpected case?
# I guess yes for most cases, because otherwise Core is leaked... but it looks across process boundary, so I'm also guessing that it is more complicated.

Note that, it turned out that some tests seem to make it very difficult
to add DCHECK into mojo::edk::Init(), e.g. LaunchTwice, unfortunately.

 
Cc: roc...@chromium.org
I think it makes sense to DCHECK and avoid calling Init() multiple times.
I don't know much about the LaunchTwice that you mentioned above, do you mean https://codesearch.chromium.org/chromium/src/content/public/test/browser_test_base.h?l=71&ct=xref_jump_to_def

+CC rockot who knows better about the edk API
Not expected and not OK. We should DCHECK. As for browser tests, we call Init very early in content initialization, so I'm surprised any test code can cause that code path to be hit twice.
Owner: hidehiko@chromium.org
Status: Assigned (was: Untriaged)
Great to know. Thank you for advice.
Let me give it a try to look into each failure.
Labels: -Pri-3 Pri-2
So, I categorized failures to four cases (two leaks in prod, and two for tests):
- nacl_helper leaks (crrev.com/2622423004)
- service_process leaks (crrev.com/2624263005)
- chromecast tests leaks (crrev.com/2627753007), and
- service_manager tests leaks (crrev.com/2628333002).

So, before adding DCHECK, these need to be fixed.
# Considering prod leaks, I set P3 -> P2.

The fixing approach above is;
- Keep relying on content::InitilizeMojo().
  - Remove mojo::edk::Init() conflicting with it.
  - For NaClMain case, NaClWin64Main does something compatible with ContentMain(), so it is moved to there.
- BrowserTest::SetUp triggers InitializeMojo(), so relying on it.
- For unittests, mojo::edk::Init()/InitIPCSupport() are called in main() (or main compatible function).

Once these four fixes are landed, we can then add DCHECK, like WIP crrev.com/2625363004, so that in future we can trap the case.

yzshen@, rockot@, could you kindly take a look at these WIP CLs?
If these are good directions to fix, I'm happy to send them to code reviews.
If there needs some big direction change, would you mind to take it over?

Thanks!

Comment 5 by roc...@chromium.org, Jan 13 2017

I would prefer that we eliminate InitializeMojo(). I don't like the idea of
using a lazy static initializer to essentially hide accidental duplicate
initialization. It should not be difficult for us to ensure that we have
consistent ownership of Mojo init/shutdown in our various binaries.


- For unittests, mojo::edk::Init()/InitIPCSupport() are called in main()
Cc: -roc...@chromium.org rockot@google.com
Cc: -lhchavez@chromium.org

Sign in to add a comment