If I inspect the crash cited above with VS related to the condition `bool reallyWait = aMayWait && (mNestedEventLoopDepth > 0 || !ShuttingDown());`, it seems that (if I can trust the `nsThread` `this` from the dump, but it looks all reasonable): - `mNestedEventLoopDepth` is `1` which means it must have been `0` when we were evaluating `reallyWait` - [`mShutdownContext`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/xpcom/threads/nsThread.h#230) is `nullptr`, thus we are not yet shutting down the main thread which would mean that `reallyWait` should have been `true` because we called `NS_ProcessNextEvent(thisThread, true);`. So I'd assume the main thread entered this state as expected before we were expecting any shutdown. IIUC `mMainThreadCV.Notify();` happens only from [`EnsureMainThreadTasksScheduled`](https://searchfox.org/mozilla-central/search?q=symbol:_ZN7mozilla14TaskController30EnsureMainThreadTasksScheduledEv&redirect=false) which in turn is called in three places: - `TaskController::ProcessPendingMTTask` which we can probably exclude to be the one we wait for as we are in there on our same stack - `TaskController::MaybeInterruptTask` - `TaskController::RunPoolThread` In the dump, all 4 `TaskController` threads are waiting on [`mThreadPoolCV.Wait();`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/xpcom/threads/TaskController.cpp#382). None of the other threads shows sign of any activity that could schedule a new task. In particular the IPC I/O thread seems to be just waiting for input, as well. The "IPCShutdownState" annotation says ` - NotifiedImpendingShutdown - HangMonitorChild::RecvRequestContentJSInterrupt (expected)` . As expected, the paired dump from the parent browser is inside `ContentParent::KillHard` run by a timer as expected. So we should [have passed here](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/dom/ipc/ContentParent.cpp#1730-1734): ``` StartForceKillTimer(); if (aSendShutDown) { MaybeAsyncSendShutDownMessage(); } ``` So if `aSendShutDown` is not `true`, **we will not send any shutdown message** to the content process but start the force kill timer, which might explain this situation if nothing else happens inside the content process. This is the case for [`ContentParent::NotifyTabDestroying`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/dom/ipc/ContentParent.cpp#2350-2351). I am wondering if we should even start the `ForceKillTimer` in this case? IIUC we send the shutdown message later as a consequence inside [`ContentParent::NotifyTabDestroyed`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/dom/ipc/ContentParent.cpp#2404) and that would be the right moment to activate the timer ?
Bug 1789803 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
If I inspect the crash cited above with VS related to the condition `bool reallyWait = aMayWait && (mNestedEventLoopDepth > 0 || !ShuttingDown());`, it seems that (if I can trust the `nsThread` `this` from the dump, but it looks all reasonable): - `mNestedEventLoopDepth` is `1` which means it must have been `0` when we were evaluating `reallyWait` - [`mShutdownContext`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/xpcom/threads/nsThread.h#230) is `nullptr`, thus we are not yet shutting down the main thread which would mean that `reallyWait` should have been `true` because we called `NS_ProcessNextEvent(thisThread, true);`. So I'd assume the main thread entered this state as expected before we were expecting any shutdown. IIUC `mMainThreadCV.Notify();` happens only from [`EnsureMainThreadTasksScheduled`](https://searchfox.org/mozilla-central/search?q=symbol:_ZN7mozilla14TaskController30EnsureMainThreadTasksScheduledEv&redirect=false) which in turn is called in three places: - `TaskController::ProcessPendingMTTask` which we can probably exclude to be the one we wait for as we are in there on our same stack - `TaskController::MaybeInterruptTask` - `TaskController::RunPoolThread` In the dump, all 4 `TaskController` threads are waiting on [`mThreadPoolCV.Wait();`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/xpcom/threads/TaskController.cpp#382). None of the other threads shows sign of any activity that could schedule a new task. In particular the IPC I/O thread seems to be just waiting for input, as well. The "IPCShutdownState" annotation says ` - NotifiedImpendingShutdown - HangMonitorChild::RecvRequestContentJSInterrupt (expected)` . As expected, the paired dump from the parent browser is inside `ContentParent::KillHard` run by a timer as expected. So we should [have passed here](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/dom/ipc/ContentParent.cpp#1730-1734): ``` StartForceKillTimer(); if (aSendShutDown) { MaybeAsyncSendShutDownMessage(); } ``` So if `aSendShutDown` is not `true`, **we will not send any shutdown message** to the content process **but start the force kill timer**, which might explain this situation if nothing else happens inside the content process. This is the case for [`ContentParent::NotifyTabDestroying`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/dom/ipc/ContentParent.cpp#2350-2351). I am wondering if we should even start the `ForceKillTimer` in this case? IIUC we send the shutdown message later as a consequence inside [`ContentParent::NotifyTabDestroyed`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/dom/ipc/ContentParent.cpp#2404) and that would be the right moment to activate the timer ?
If I inspect the crash cited above with VS related to the condition `bool reallyWait = aMayWait && (mNestedEventLoopDepth > 0 || !ShuttingDown());`, it seems that (if I can trust the `nsThread` `this` from the dump, but it looks all reasonable): - `mNestedEventLoopDepth` is `1` which means it must have been `0` when we were evaluating `reallyWait` - [`mShutdownContext`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/xpcom/threads/nsThread.h#230) is `nullptr`, thus we are not yet shutting down the main thread which would mean that `reallyWait` should have been `true` because we called `NS_ProcessNextEvent(thisThread, true);`. So I'd assume the main thread entered this state as expected before we were expecting any shutdown. IIUC `mMainThreadCV.Notify();` happens only from [`EnsureMainThreadTasksScheduled`](https://searchfox.org/mozilla-central/search?q=symbol:_ZN7mozilla14TaskController30EnsureMainThreadTasksScheduledEv&redirect=false) which in turn is called in three places: - `TaskController::ProcessPendingMTTask` which we can probably exclude to be the one we wait for as we are in there on our same stack - `TaskController::MaybeInterruptTask` - `TaskController::RunPoolThread` In the dump, all 4 `TaskController` threads are waiting on [`mThreadPoolCV.Wait();`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/xpcom/threads/TaskController.cpp#382). None of the other threads shows sign of any activity that could schedule a new task. In particular the IPC I/O thread seems to be just waiting for input, as well. The "IPCShutdownState" annotation says ` - NotifiedImpendingShutdown - HangMonitorChild::RecvRequestContentJSInterrupt (expected)` . As expected, the paired dump from the parent browser is inside `ContentParent::KillHard` run by a timer as expected. So we should [have passed here](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/dom/ipc/ContentParent.cpp#1730-1734): ``` SignalImpendingShutdownToContentJS(); StartForceKillTimer(); if (aSendShutDown) { MaybeAsyncSendShutDownMessage(); } ``` So if `aSendShutDown` is not `true`, **we will not send any shutdown message** to the content process **but interrupt content JS and start the force kill timer**, which might explain this situation if nothing else happens inside the content process. This is the case for [`ContentParent::NotifyTabDestroying`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/dom/ipc/ContentParent.cpp#2350-2351). I am wondering if we should even start the `ForceKillTimer` in this case? IIUC we send the shutdown message later as a consequence inside [`ContentParent::NotifyTabDestroyed`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/dom/ipc/ContentParent.cpp#2404) and that would be the right moment to activate the timer ?
If I inspect the crash cited above with VS related to the condition `bool reallyWait = aMayWait && (mNestedEventLoopDepth > 0 || !ShuttingDown());`, it seems that (if I can trust the `nsThread` `this` from the dump, but it looks all reasonable): - `mNestedEventLoopDepth` is `1` which means it must have been `0` when we were evaluating `reallyWait` - [`mShutdownContext`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/xpcom/threads/nsThread.h#230) is `nullptr`, thus we are not yet shutting down the main thread which would mean that `reallyWait` should have been `true` because we called `NS_ProcessNextEvent(thisThread, true);`. So I'd assume the main thread entered this state as expected before we were expecting any shutdown. IIUC `mMainThreadCV.Notify();` happens only from [`EnsureMainThreadTasksScheduled`](https://searchfox.org/mozilla-central/search?q=symbol:_ZN7mozilla14TaskController30EnsureMainThreadTasksScheduledEv&redirect=false) which in turn is called in three places: - `TaskController::ProcessPendingMTTask` which we can probably exclude to be the one we wait for as we are in there on our same stack - `TaskController::MaybeInterruptTask` - `TaskController::RunPoolThread` In the dump, all 4 `TaskController` threads are waiting on [`mThreadPoolCV.Wait();`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/xpcom/threads/TaskController.cpp#382). None of the other threads shows sign of any activity that could schedule a new task. In particular the IPC I/O thread seems to be just waiting for input, as well. The "IPCShutdownState" annotation says ` - NotifiedImpendingShutdown - HangMonitorChild::RecvRequestContentJSInterrupt (expected)` . As expected, the paired dump from the parent browser is inside `ContentParent::KillHard` run by a timer. So we should [have passed here](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/dom/ipc/ContentParent.cpp#1729-1734): ``` SignalImpendingShutdownToContentJS(); StartForceKillTimer(); if (aSendShutDown) { MaybeAsyncSendShutDownMessage(); } ``` So if `aSendShutDown` is not `true`, **we will not send any shutdown message** to the content process **but interrupt content JS and start the force kill timer**, which might explain this situation if nothing else happens inside the content process. This is the case for [`ContentParent::NotifyTabDestroying`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/dom/ipc/ContentParent.cpp#2350-2351). I am wondering if we should even start the `ForceKillTimer` in this case? IIUC we send the shutdown message later as a consequence inside [`ContentParent::NotifyTabDestroyed`](https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/dom/ipc/ContentParent.cpp#2404) and that would be the right moment to activate the timer ?