[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