Clear PermissionStatus::m_service in pre-finalizer

Clear PermissionStatus::m_service in pre-finalizer

Otherwise, there's a risk that Mojo's callback accesses the PermissionStatus object
that is going to die in lazy sweeping. To prevent that from happening,
we need to clear the service pointer before the lazy sweeping starts.

BUG=653688

[haraken, 2016-10-07 01:45:07]

haraken@chromium.org changed reviewers:
+ mlamouri@chromium.org, reillyg@chromium.org

[haraken, 2016-10-07 01:45:07]

PTAL

[haraken, 2016-10-07 01:45:16]

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

[commit-bot: I haz the power, 2016-10-07 01:45:30]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Reilly Grant (use Gerrit), 2016-10-07 02:05:49]

We talked about this offline but for posterity: This isn't the solution we want.
wrapWeakPersistent() should already be preventing Mojo callbacks from accessing
the PermissionStatus object during lazy sweeping. The problem is that on
shutdown (the crash in the linked bug is during MessageLoop destruction) the
Oilpan heap is being destroyed without invalidating weak persistent pointers.

[commit-bot: I haz the power, 2016-10-07 02:52:28]

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

[commit-bot: I haz the power, 2016-10-07 02:52:28]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[haraken, 2016-10-08 02:05:15]

On 2016/10/07 02:05:49, Reilly Grant wrote:
> We talked about this offline but for posterity: This isn't the solution we
want.
> wrapWeakPersistent() should already be preventing Mojo callbacks from
accessing
> the PermissionStatus object during lazy sweeping. The problem is that on
> shutdown (the crash in the linked bug is during MessageLoop destruction) the
> Oilpan heap is being destroyed without invalidating weak persistent pointers.

I tried to implement the approach but noticed that it won't work.

The problem here is NOT that ~MessageLoop is touching an Oilpan object pointed
to by the weak persistent handle but that ~MessageLoop is touching the weak
persistent handle. The memory region on which the weak persistent handle was
allocated has already been cleared by Oilpan's shutdown, so it crashes. In other
words, trying to clear weak persistent handles in Oilpan's shutdown won't help.

I suspect that there will be no easy work-around to this issue. The only way to
solve this problem is to leak MessageLoop or remove the shutdown sequence. I'm
actively working on it in https://codereview.chromium.org/2309153002, but it
will take a bit more time to land it.