Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-79202

PinnedConnectionTaskExecutor can hang when shutting down

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 7.1.0-rc4, 7.0.6, 6.0.14
    • Affects Version/s: None
    • Component/s: None
    • None
    • Service Arch
    • Fully Compatible
    • ALL
    • v7.0, v6.0
    • Service Arch 2023-08-21, Service Arch 2023-09-04, Service Arch 2023-09-18, Service Arch 2023-10-02
    • 0

      PinnedConnectionTaskExecutor creates a lambda with a shared_ptr to itself here: https://github.com/mongodb/mongo/blob/4ff092d683be418230ef28fa3f3c81833b82c570/src/mongo/executor/pinned_connection_task_executor.cpp#L323 that can extend the PinnedConnectionTaskExecutor's lifetime (the lambda is scheduled to run on the ThreadPoolTaskExecutor the PinnedConnectionTaskExecutor proxies over)

      If the shared_ptr stored in that lambda is the last reference to the PinnedConnectionTaskExecutor, the PinnedConnectionTaskExecutor will be destroyed upon that lambda's destruction. This can result in the destruction of the PCTE's shared_ptr to the underlying TPTE, which will call join on that TPTE. However, because the lambda is executed on one of the TPTE's own threads, we violate the TaskExecutor::join contract and may hang (we are stuck waiting for our own callback to finish).

      This should only be a problem in tests, because the only production-use of PinnedConnectionTaskExecutor is TaskExecutorCursor, which uses the mongotExecutor as the underlying TPTE. A shared_ptr to that object is stored in a ServiceContext decoration and is only destroyed when the ServiceContext is. Since search is mongod-only, and we don't destroy the serviceContext ever in mongod in production (and we destroy all user operations/clients first), it shouldn't be possible for any PCTE callback to have the last reference to the underlying TPTE.

            Assignee:
            george.wangensteen@mongodb.com George Wangensteen
            Reporter:
            george.wangensteen@mongodb.com George Wangensteen
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: