https://treeherder.mozilla.org/logviewer?job_id=457742524&repo=autoland&lineNumber=15056 is in `netwerk/cookie/test/browser/browser_indexedDB.js` but seems not to be the shutdown hang we want to track here. There I read right before the crash: ``` [task 2024-05-10T10:37:56.871Z] 10:37:56 INFO - GECKO(19453) | [Child 21829: Main Thread]: D/WorkerShutdownDump Found ActiveWorker (dedicated): blob:https://example.com/46757b52-44b2-43e6-8cf6-078a37665c02 [task 2024-05-10T10:37:56.871Z] 10:37:56 INFO - GECKO(19453) | [Child 21829: Main Thread]: D/WorkerShutdownDump Principal: https://example.com [task 2024-05-10T10:37:56.872Z] 10:37:56 INFO - GECKO(19453) | [Child 21829: Main Thread]: D/WorkerShutdownDump LoadingPrincipal: https://example.com [task 2024-05-10T10:37:56.873Z] 10:37:56 INFO - GECKO(19453) | [Child 21829: Main Thread]: D/WorkerShutdownDump CrashInfo: IsChromeWorker(false)|IDBOpenDBRequest ``` so we are shutting down we see [this worker ref being held](https://searchfox.org/mozilla-central/rev/a18a7c526cf3c531f2fc24db4f0dffbc16290a7e/dom/indexedDB/IDBRequest.cpp347). https://treeherder.mozilla.org/logviewer?job_id=457692462&repo=autoland&lineNumber=3985 is in `/IndexedDB/structured-clone.any.worker.html?61-80` and again is that different thing. There seem to be more of these and we might want a separate bug for this. However, there is also the possibility that this is a symptom of having moved IDB connections to work on a thread pool and we see some underlying shutdown issue of thread pools in general. Once a thread pool is asked to shutdown, it will refuse [to accept any further events](https://searchfox.org/mozilla-central/rev/1f46481d6c16f27c989e72b898fd1fddce9f445f/xpcom/threads/nsThreadPool.cpp#91-93) even if those come from a thread running inside the same pool [while we are draining the remaining events](https://searchfox.org/mozilla-central/rev/1f46481d6c16f27c989e72b898fd1fddce9f445f/xpcom/threads/nsThreadPool.cpp#267,275-277) (the loop continues until there are events). That means, that any processing that relies on a sequence of 1. "A on other thread dispatches B to the pool" 2. "B runs on pool and dispatches C to the same pool" 3. "C runs on pool and dispatches D to original thread to resolve some promise/close some callback roundtrip/whatever" would break, if the pool is asked to shutdown after 1. but before 2. I think it is worth filing a bug to rule this out.
Bug 1358898 Comment 679 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
https://treeherder.mozilla.org/logviewer?job_id=457742524&repo=autoland&lineNumber=15056 is in `netwerk/cookie/test/browser/browser_indexedDB.js` but seems not to be the shutdown hang we want to track here. There I read right before the crash: ``` [task 2024-05-10T10:37:56.871Z] 10:37:56 INFO - GECKO(19453) | [Child 21829: Main Thread]: D/WorkerShutdownDump Found ActiveWorker (dedicated): blob:https://example.com/46757b52-44b2-43e6-8cf6-078a37665c02 [task 2024-05-10T10:37:56.871Z] 10:37:56 INFO - GECKO(19453) | [Child 21829: Main Thread]: D/WorkerShutdownDump Principal: https://example.com [task 2024-05-10T10:37:56.872Z] 10:37:56 INFO - GECKO(19453) | [Child 21829: Main Thread]: D/WorkerShutdownDump LoadingPrincipal: https://example.com [task 2024-05-10T10:37:56.873Z] 10:37:56 INFO - GECKO(19453) | [Child 21829: Main Thread]: D/WorkerShutdownDump CrashInfo: IsChromeWorker(false)|IDBOpenDBRequest ``` so while we are shutting down we see [this worker ref being held](https://searchfox.org/mozilla-central/rev/a18a7c526cf3c531f2fc24db4f0dffbc16290a7e/dom/indexedDB/IDBRequest.cpp347). https://treeherder.mozilla.org/logviewer?job_id=457692462&repo=autoland&lineNumber=3985 is in `/IndexedDB/structured-clone.any.worker.html?61-80` and again is that different thing. There seem to be more of these and we might want a separate bug for this. However, there is also the possibility that this is a symptom of having moved IDB connections to work on a thread pool and we see some underlying shutdown issue of thread pools in general. Once a thread pool is asked to shutdown, it will refuse [to accept any further events](https://searchfox.org/mozilla-central/rev/1f46481d6c16f27c989e72b898fd1fddce9f445f/xpcom/threads/nsThreadPool.cpp#91-93) even if those come from a thread running inside the same pool [while we are draining the remaining events](https://searchfox.org/mozilla-central/rev/1f46481d6c16f27c989e72b898fd1fddce9f445f/xpcom/threads/nsThreadPool.cpp#267,275-277) (the loop continues until there are events). That means, that any processing that relies on a sequence of 1. "A on other thread dispatches B to the pool" 2. "B runs on pool and dispatches C to the same pool" 3. "C runs on pool and dispatches D to original thread to resolve some promise/close some callback roundtrip/whatever" would break, if the pool is asked to shutdown after 1. but before 2. I think it is worth filing a bug to rule this out.