Bug 1633342 Comment 41 Edit History

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

Original comment by
on 
Looking at [shutdownhang mozilla::TaskController::GetRunnableForMTTask mozilla::net::nsHttpConnectionMgr::Shutdown](https://crash-stats.mozilla.org/signature/?signature=shutdownhang%20%7C%20mozilla%3A%3ATaskController%3A%3AGetRunnableForMTTask%20%7C%20nsThread%3A%3AShutdown%20%7C%20mozilla%3A%3Anet%3A%3AnsSocketTransportService%3A%3AShutdownThread&date=%3E%3D2020-10-23T13%3A27%3A00.000Z&date=%3C2020-10-30T13%3A27%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports).

In all th reports I clicked on, the SocketThread is stuck while shutting down the [SSL Cert threadpool](https://hg.mozilla.org/releases/mozilla-beta/annotate/25ae363f586ea237fa86be992f385dadf706cbd9/security/manager/ssl/SSLServerCertVerification.cpp#l187).

Looking at the [shutdown function](https://hg.mozilla.org/releases/mozilla-release/annotate/bdb93bd9b26d6480c04eeda33896e826a8e9255e/xpcom/threads/nsThreadPool.cpp#l397), it seems we shutdown the threads in the order we created them (and wait for each single thread before we loop). I see in the first three reports I clicked on, that `SSL Cert #1` is still alive, and am assuming that it processes some long lasting event when the shutdown event comes in, such that we never get to process the shutdown event.

In two cases it is stuck in [`nsNSSComponent::BlockUntilLoadableCertsLoaded()`](https://hg.mozilla.org/releases/mozilla-beta/annotate/25ae363f586ea237fa86be992f385dadf706cbd9/security/manager/ssl/nsNSSComponent.cpp#l857), in the other case [`mozilla::psm::NSSCertDBTrustDomain::GetCertTrust`](https://hg.mozilla.org/releases/mozilla-release/annotate/bdb93bd9b26d6480c04eeda33896e826a8e9255e/security/certverifier/NSSCertDBTrustDomain.cpp#l492) seems stuck.
Revision 1 by
on 
Looking at [shutdownhang mozilla::TaskController::GetRunnableForMTTask mozilla::net::nsHttpConnectionMgr::Shutdown](https://crash-stats.mozilla.org/signature/?signature=shutdownhang%20%7C%20mozilla%3A%3ATaskController%3A%3AGetRunnableForMTTask%20%7C%20nsThread%3A%3AShutdown%20%7C%20mozilla%3A%3Anet%3A%3AnsSocketTransportService%3A%3AShutdownThread&date=%3E%3D2020-10-23T13%3A27%3A00.000Z&date=%3C2020-10-30T13%3A27%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports).

In all the reports I clicked on, the SocketThread is stuck while shutting down the [SSL Cert threadpool](https://hg.mozilla.org/releases/mozilla-beta/annotate/25ae363f586ea237fa86be992f385dadf706cbd9/security/manager/ssl/SSLServerCertVerification.cpp#l187).

Looking at the [shutdown function](https://hg.mozilla.org/releases/mozilla-release/annotate/bdb93bd9b26d6480c04eeda33896e826a8e9255e/xpcom/threads/nsThreadPool.cpp#l397), it seems we shutdown the threads in the order we created them (and wait for each single thread before we loop). I see in the first three reports I clicked on, that `SSL Cert #1` is still alive, and am assuming that it processes some long lasting event when the shutdown event comes in, such that we never get to process the shutdown event.

In two cases it is stuck in [`nsNSSComponent::BlockUntilLoadableCertsLoaded()`](https://hg.mozilla.org/releases/mozilla-beta/annotate/25ae363f586ea237fa86be992f385dadf706cbd9/security/manager/ssl/nsNSSComponent.cpp#l857), in the other case [`mozilla::psm::NSSCertDBTrustDomain::GetCertTrust`](https://hg.mozilla.org/releases/mozilla-release/annotate/bdb93bd9b26d6480c04eeda33896e826a8e9255e/security/certverifier/NSSCertDBTrustDomain.cpp#l492) seems stuck.
Revision 2 by
on 
Looking at [shutdownhang | mozilla::TaskController::GetRunnableForMTTask | nsThread::Shutdown | mozilla::net::nsSocketTransportService::ShutdownThread](https://crash-stats.mozilla.org/signature/?signature=shutdownhang%20%7C%20mozilla%3A%3ATaskController%3A%3AGetRunnableForMTTask%20%7C%20nsThread%3A%3AShutdown%20%7C%20mozilla%3A%3Anet%3A%3AnsSocketTransportService%3A%3AShutdownThread&date=%3E%3D2020-10-23T13%3A27%3A00.000Z&date=%3C2020-10-30T13%3A27%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports).

In all the reports I clicked on, the SocketThread is stuck while shutting down the [SSL Cert threadpool](https://hg.mozilla.org/releases/mozilla-beta/annotate/25ae363f586ea237fa86be992f385dadf706cbd9/security/manager/ssl/SSLServerCertVerification.cpp#l187).

Looking at the [shutdown function](https://hg.mozilla.org/releases/mozilla-release/annotate/bdb93bd9b26d6480c04eeda33896e826a8e9255e/xpcom/threads/nsThreadPool.cpp#l397), it seems we shutdown the threads in the order we created them (and wait for each single thread before we loop). I see in the first three reports I clicked on, that `SSL Cert #1` is still alive, and am assuming that it processes some long lasting event when the shutdown event comes in, such that we never get to process the shutdown event.

In two cases it is stuck in [`nsNSSComponent::BlockUntilLoadableCertsLoaded()`](https://hg.mozilla.org/releases/mozilla-beta/annotate/25ae363f586ea237fa86be992f385dadf706cbd9/security/manager/ssl/nsNSSComponent.cpp#l857), in the other case [`mozilla::psm::NSSCertDBTrustDomain::GetCertTrust`](https://hg.mozilla.org/releases/mozilla-release/annotate/bdb93bd9b26d6480c04eeda33896e826a8e9255e/security/certverifier/NSSCertDBTrustDomain.cpp#l492) seems stuck.

Back to Bug 1633342 Comment 41