Coverity analysis defect 175492: Value not atomically updated

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Cluster Scalability
    • ALL
    • None
    • 3
    • TBD
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Value not atomically updated

      The result of the update will be determined by the interleaving of thread execution. Non-atomic update of a concurrently shared value
      /data/mci/7b5199136d945ea4e1751b7b3bd3d384/bazel_cache/658afbbc91b088dd7e554f8eea998579/execroot/_main/src/mongo/db/s/migration_chunk_cloner_source.cpp:655: ATOMICITY 175492 Assuming "lk" is locked since it is unlocked without prior lock in this function.
      /data/mci/7b5199136d945ea4e1751b7b3bd3d384/bazel_cache/658afbbc91b088dd7e554f8eea998579/execroot/_main/src/mongo/db/s/migration_chunk_cloner_source.cpp:684: ATOMICITY 175492 Assigning data that might be protected by the lock to "execState".
      /data/mci/7b5199136d945ea4e1751b7b3bd3d384/bazel_cache/658afbbc91b088dd7e554f8eea998579/execroot/_main/src/mongo/db/s/migration_chunk_cloner_source.cpp:689: ATOMICITY 175492 Unlocking "lk._M_device". "execState" might now be unreliable because other threads can now change the data that it depends on.
      /data/mci/7b5199136d945ea4e1751b7b3bd3d384/bazel_cache/658afbbc91b088dd7e554f8eea998579/execroot/_main/src/mongo/db/s/migration_chunk_cloner_source.cpp:698: ATOMICITY 175492 Unlocking "lk". "execState" might now be unreliable because other threads can now change the data that it depends on.
      /data/mci/7b5199136d945ea4e1751b7b3bd3d384/bazel_cache/658afbbc91b088dd7e554f8eea998579/execroot/_main/src/mongo/db/s/migration_chunk_cloner_source.cpp:715: ATOMICITY 175492 Locking "this->_mutex" again.
      /data/mci/7b5199136d945ea4e1751b7b3bd3d384/bazel_cache/658afbbc91b088dd7e554f8eea998579/execroot/_main/src/mongo/db/s/migration_chunk_cloner_source.cpp:716: ATOMICITY 175492 Using an unreliable value of "execState" inside the second locked section. If the data that "execState" depends on was changed by another thread, this use might be incorrect.

            Assignee:
            Unassigned
            Reporter:
            Coverity Collector User
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: