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

Cursor leak in aggregation that requires merging on shard

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.4.19, 5.0.15, 6.0.4, 6.2.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Fully Compatible
    • ALL
    • v6.1, v6.0, v5.0, v4.4
    • Hide

      ./buildscripts/resmoke.py run --storageEngine=wiredTiger --storageEngineCacheSizeGB=.50 --suite=sharding jstests/sharding/repro-server-65259.js --log=file

      ./buildscripts/resmoke.py run --storageEngine=wiredTiger --storageEngineCacheSizeGB=.50 --suite=sharding jstests/sharding/repro-server-65259.js --log=file 0001-Repro-SERVER-65259.patch
    • QE 2022-09-19, QE 2022-10-03
    • 4

      Consider an aggregation that requires merging on a shard. First, mongos opens the split cursors on the shards. Later, in order to establish the merge cursor, dispatchMergingPipeline is called and the split cursors ownership is transferred to it. There, sharded_agg_helpers::addMergeCursorsSource will transfer the split cursors ownership to the merge pipeline. Finally, the merge cursor will be established. However, if this fails (for instance if the shard is in the middle of a migration critical section), 'storePossibleCursor' will return here and then the split cursors ownership is dismissed from the mergePipeline. However, because the merge cursor was not really established, the shard did not take ownership of those cursors either, so they are leaked.

            mickey.winters@mongodb.com Mickey Winters
            jordi.serra-torrens@mongodb.com Jordi Serra Torrens
            0 Vote for this issue
            8 Start watching this issue