[llvm] r275516 - [llvm-cov] Fix a use-after-free
Vedant Kumar via llvm-commits
llvm-commits at lists.llvm.org
Thu Jul 14 18:19:37 PDT 2016
Author: vedantk
Date: Thu Jul 14 20:19:36 2016
New Revision: 275516
URL: http://llvm.org/viewvc/llvm-project?rev=275516&view=rev
Log:
[llvm-cov] Fix a use-after-free
Taking a lock before appending to a vector does no good unless threads
reading from the vector also take the lock, because the vector could be
re-sized.
I don't have a good isolated test for this. I found the issue with ASan
while testing a large project. I'm working on a bot that does this.
Modified:
llvm/trunk/tools/llvm-cov/CodeCoverage.cpp
Modified: llvm/trunk/tools/llvm-cov/CodeCoverage.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-cov/CodeCoverage.cpp?rev=275516&r1=275515&r2=275516&view=diff
==============================================================================
--- llvm/trunk/tools/llvm-cov/CodeCoverage.cpp (original)
+++ llvm/trunk/tools/llvm-cov/CodeCoverage.cpp Thu Jul 14 20:19:36 2016
@@ -151,6 +151,7 @@ void CodeCoverageTool::addCollectedPath(
ErrorOr<const MemoryBuffer &>
CodeCoverageTool::getSourceFile(StringRef SourceFile) {
// If we've remapped filenames, look up the real location for this file.
+ std::unique_lock<std::mutex> Guard{LoadedSourceFilesLock};
if (!RemappedFilenames.empty()) {
auto Loc = RemappedFilenames.find(SourceFile);
if (Loc != RemappedFilenames.end())
@@ -164,7 +165,6 @@ CodeCoverageTool::getSourceFile(StringRe
deferError(EC.message(), SourceFile);
return EC;
}
- std::unique_lock<std::mutex> Guard{LoadedSourceFilesLock};
LoadedSourceFiles.emplace_back(SourceFile, std::move(Buffer.get()));
return *LoadedSourceFiles.back().second;
}
More information about the llvm-commits
mailing list