Bug 1616079 Comment 7 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Workaround in comment 1 is not workable. Using RefPtr on WorkerRunnable::mWorkerPrivate changes WorkerPrivate's life cycle. And it also makes WorkerPrivate be freed on the unexpected thread. So we meet lots of crashes in ~WorkerPrivate().

I am not sure if using RefPtr holding WorkerPrivate in InitializeWorkerRunnable is suitable or not, since the WorkerPrivate's life cycle still changed. 

What my guess is RemoteWorkerChild::mState probably is switched to Terminated/PendingTerminate for some reasons, i.e. shutdown, before dispatching the InitializeWorkerRunnable. The state switching makes the WorkerPrivate strong reference on Pending state be released.

https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/dom/workers/remoteworkers/RemoteWorkerChild.cpp#446

But the following logic doesn't expect the state switching case. It seems to expect the RemoteWorkerChild::mState should be Pending

https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/dom/workers/remoteworkers/RemoteWorkerChild.cpp#452-459

Here is a workaround to check if RemoteWorkerChild::mState is Pending before dispatching InitializeWorkerRunnable. The difference from holding a RefPtr<WorkerPrivate> in InitializeWorkerRunnable is this workaround does not change any object's life cycle.
Workaround in comment 1 does not work. Using RefPtr on WorkerRunnable::mWorkerPrivate changes WorkerPrivate's life cycle. And it also makes WorkerPrivate be freed on the unexpected thread. So we meet lots of crashes in ~WorkerPrivate().

I am not sure if using RefPtr holding WorkerPrivate in InitializeWorkerRunnable is suitable or not, since the WorkerPrivate's life cycle still changed. 

What my guess is RemoteWorkerChild::mState probably is switched to Terminated/PendingTerminate for some reasons, i.e. shutdown, before dispatching the InitializeWorkerRunnable. The state switching makes the WorkerPrivate strong reference on Pending state be released.

https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/dom/workers/remoteworkers/RemoteWorkerChild.cpp#446

But the following logic doesn't expect the state switching case. It seems to expect the RemoteWorkerChild::mState should be Pending

https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/dom/workers/remoteworkers/RemoteWorkerChild.cpp#452-459

Here is a workaround to check if RemoteWorkerChild::mState is Pending before dispatching InitializeWorkerRunnable. The difference from holding a RefPtr<WorkerPrivate> in InitializeWorkerRunnable is this workaround does not change any object's life cycle.

Back to Bug 1616079 Comment 7