From 40f2b65008731b8c12397ee7866bcd50b6c8b814 Mon Sep 17 00:00:00 2001 From: Azat Khuzhin Date: Thu, 10 Dec 2020 09:33:53 -0800 Subject: [PATCH] Eliminate possible race between LockFile() vs UnlockFile() (#7721) Summary: LockFile() accessing LockHoldingInfo (element of locked_files) by reference after mutex_locked_files had been released. Pull Request resolved: https://github.com/facebook/rocksdb/pull/7721 Reviewed By: pdillinger Differential Revision: D25431839 Pulled By: jay-zhuang fbshipit-source-id: eefee93f12a8016a98e2466e442af2605b3e2a5e --- env/fs_posix.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/env/fs_posix.cc b/env/fs_posix.cc index 92133eb22..c38c62811 100644 --- a/env/fs_posix.cc +++ b/env/fs_posix.cc @@ -766,9 +766,9 @@ class PosixFileSystem : public FileSystem { // closed, all locks the process holds for that *file* are released const auto it_success = locked_files.insert({fname, lhi}); if (it_success.second == false) { + LockHoldingInfo prev_info = it_success.first->second; mutex_locked_files.Unlock(); errno = ENOLCK; - LockHoldingInfo& prev_info = it_success.first->second; // Note that the thread ID printed is the same one as the one in // posix logger, but posix logger prints it hex format. return IOError("lock hold by current process, acquire time " +