mojo::edk::Init() sometimes called twice or more. |
|||||
Issue descriptionChrome 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.
,
Jan 6 2017
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.
,
Jan 6 2017
Great to know. Thank you for advice. Let me give it a try to look into each failure.
,
Jan 13 2017
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!
,
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()
,
Oct 17
,
Jan 7
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by yzshen@chromium.org
, Jan 5 2017