Fix shutdown issues with IPC and gralloc layers

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
5 years ago
a year ago

People

(Reporter: jgilbert, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
In bug 914823, we (appear to be going to) hold a weak-pointer to the surface allocator. This way, when it gets destroyed too early, we know we can't access it anymore.

While this more-or-less works for main-thread code, off-main-thread code (like workers) would need to temporarily promote this to a strong-ptr, so we have the same issues of holding a strong-ptr to the allocator. (It will try to use the now-dead IPC subsystem)

We need a better fix. What form this should take is still in discussion. We either need to do IPC teardown only after GFX teardown, or have a better way to handle having IPC torn out from under us. Really, we need a better way to handle IPC-tear-outs, since I understand this can happen if one of the processes crashes.

Comment 1

5 years ago
Strongly promoting the weakptr to a strong ptr won't fix anything, since that doesn't guarantee that the object is going to be in a consistent state.  Specifically if the IPC subsystem is dead, even if you keep an actor alive, it won't be able to do anything useful any more, and it seems to me like the weakptr trick will just move the crash elsewhere.

Can't we just destroy the IPC subsystem as the last thing we do in our shutdown, specifically after the last GC+CC when the DOM objects finally die?
It's also very easy to set a flag on the stronly-owned actor when the IPC parts die so that we don't crash later.
weakptr is just going to necessary to prevent dual/circular strong pointer references. Basically we are thinking about to use stronly-owned actor. Necessity of weakptr is just under consideration.
Android's referenced object support the following functions. If gecko's referenced object supports such functions, implementation becomes easiser.
- void onFirstRef();
- void onLastStrongRef();
- bool onIncStrongAttempted();
- void onLastWeakRef();

http://androidxref.com/4.3_r2.1/xref/frameworks/native/include/utils/RefBase.h#145
I feel that the implementation patterns seems to be categorized to following patterns.
-[1] single threaded, single user
-[2] single threaded, multiple user
-[3] multiple threaded, single user
-[4] multiple threaded, multiple user
Android uses "thread safe weak pointer" in c++ code, but it's usage is limited only to observer pattern like the following.
  http://androidxref.com/4.3_r2.1/xref/frameworks/av/media/libstagefright/AwesomePlayer.cpp#588

I also feel that weak pointer usage should be basically limited to such observer pattern. If we want to use weak pointer in another use case, it might be better to think about changing the architecture to fix the problem. And rethink about whether the weak pointer is necessary in that case.
patch in Bug 914823 seems not fit to the weak pointer usage pattern in Comment 6. I think that it is OK as a short time solution to fix the problem. But longer term, we should change the weak pointer usage by correcting an architecture. We already talked to change ISurfaceAllocator independent from LayerTransaction somewhere a little bit. It seems to solve the weak pointer usage in Bug 914823.

Comment 8

a year ago
Is this bug still valid or can it be closed?
Flags: needinfo?(jgilbert)
(Reporter)

Comment 9

a year ago
This is a b2g-only bug.
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(jgilbert)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.