Bug 1751948 - Part 5: Ensure we don't release ActorLifecycleProxy while holding MessageChannel's Monitor, r=jld

Releasing ActorLifecycleProxy can lead to the IToplevelProtocol being
destroyed, due to the reference being the last reference. If this happens, we
can deadlock due to the MessageChannel embedded in IToplevelProtocol locking
mMonitor during its' destructor. This patch moves acquiring the proxy earlier
in the method, so that we do not deadlock in this case any longer.

Differential Revision: https://phabricator.services.mozilla.com/D137169
This commit is contained in:
Nika Layzell
2022-02-28 21:01:48 +00:00
parent f6a15db447
commit d282e33143
2 changed files with 27 additions and 17 deletions

View File

@@ -367,13 +367,14 @@ class MessageChannel : HasResultCodes {
bool HasPendingEvents();
void ProcessPendingRequests(AutoEnterTransaction& aTransaction);
bool ProcessPendingRequest(Message&& aUrgent);
void ProcessPendingRequests(ActorLifecycleProxy* aProxy,
AutoEnterTransaction& aTransaction);
bool ProcessPendingRequest(ActorLifecycleProxy* aProxy, Message&& aUrgent);
void EnqueuePendingMessages();
// Dispatches an incoming message to its appropriate handler.
void DispatchMessage(Message&& aMsg);
void DispatchMessage(ActorLifecycleProxy* aProxy, Message&& aMsg);
// DispatchMessage will route to one of these functions depending on the
// protocol type of the message.
@@ -516,7 +517,7 @@ class MessageChannel : HasResultCodes {
};
bool ShouldRunMessage(const Message& aMsg);
void RunMessage(MessageTask& aTask);
void RunMessage(ActorLifecycleProxy* aProxy, MessageTask& aTask);
typedef LinkedList<RefPtr<MessageTask>> MessageQueue;
typedef std::map<size_t, UniquePtr<UntypedCallbackHolder>> CallbackMap;