2012-01-30 04:15:10 +08:00
|
|
|
//===--- LockFileManager.cpp - File-level Locking Utility------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
2016-08-24 01:14:32 +08:00
|
|
|
|
2012-01-30 04:15:10 +08:00
|
|
|
#include "llvm/Support/LockFileManager.h"
|
2016-08-24 01:14:32 +08:00
|
|
|
#include "llvm/ADT/None.h"
|
|
|
|
#include "llvm/ADT/SmallVector.h"
|
2013-08-07 06:51:21 +08:00
|
|
|
#include "llvm/ADT/StringExtras.h"
|
2014-06-14 01:20:48 +08:00
|
|
|
#include "llvm/Support/Errc.h"
|
2016-08-24 01:14:32 +08:00
|
|
|
#include "llvm/Support/ErrorOr.h"
|
2012-01-30 04:15:10 +08:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
2013-08-07 06:51:21 +08:00
|
|
|
#include "llvm/Support/MemoryBuffer.h"
|
2015-06-30 01:08:41 +08:00
|
|
|
#include "llvm/Support/Signals.h"
|
2017-06-06 19:49:48 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2016-08-24 01:14:32 +08:00
|
|
|
#include <cerrno>
|
|
|
|
#include <ctime>
|
|
|
|
#include <memory>
|
2012-01-30 04:15:10 +08:00
|
|
|
#include <sys/stat.h>
|
2012-12-04 00:50:05 +08:00
|
|
|
#include <sys/types.h>
|
2017-06-06 19:49:48 +08:00
|
|
|
#include <system_error>
|
|
|
|
#include <tuple>
|
2018-08-23 17:42:58 +08:00
|
|
|
#ifdef _WIN32
|
2012-01-30 04:15:10 +08:00
|
|
|
#include <windows.h>
|
|
|
|
#endif
|
|
|
|
#if LLVM_ON_UNIX
|
|
|
|
#include <unistd.h>
|
|
|
|
#endif
|
2015-06-30 06:16:39 +08:00
|
|
|
|
|
|
|
#if defined(__APPLE__) && defined(__MAC_OS_X_VERSION_MIN_REQUIRED) && (__MAC_OS_X_VERSION_MIN_REQUIRED > 1050)
|
|
|
|
#define USE_OSX_GETHOSTUUID 1
|
|
|
|
#else
|
|
|
|
#define USE_OSX_GETHOSTUUID 0
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if USE_OSX_GETHOSTUUID
|
|
|
|
#include <uuid/uuid.h>
|
|
|
|
#endif
|
2016-08-24 01:14:32 +08:00
|
|
|
|
2012-01-30 04:15:10 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Attempt to read the lock file with the given name, if it exists.
|
2012-01-30 04:15:10 +08:00
|
|
|
///
|
|
|
|
/// \param LockFileName The name of the lock file to read.
|
|
|
|
///
|
|
|
|
/// \returns The process ID of the process that owns this lock file
|
|
|
|
Optional<std::pair<std::string, int> >
|
|
|
|
LockFileManager::readLockFile(StringRef LockFileName) {
|
|
|
|
// Read the owning host and PID out of the lock file. If it appears that the
|
|
|
|
// owning process is dead, the lock file is invalid.
|
2014-07-07 01:43:13 +08:00
|
|
|
ErrorOr<std::unique_ptr<MemoryBuffer>> MBOrErr =
|
|
|
|
MemoryBuffer::getFile(LockFileName);
|
|
|
|
if (!MBOrErr) {
|
2014-03-21 09:25:37 +08:00
|
|
|
sys::fs::remove(LockFileName);
|
2013-08-07 09:22:04 +08:00
|
|
|
return None;
|
2014-03-21 09:25:37 +08:00
|
|
|
}
|
2014-08-01 22:31:55 +08:00
|
|
|
MemoryBuffer &MB = *MBOrErr.get();
|
2013-08-07 09:22:04 +08:00
|
|
|
|
|
|
|
StringRef Hostname;
|
|
|
|
StringRef PIDStr;
|
2014-08-01 22:31:55 +08:00
|
|
|
std::tie(Hostname, PIDStr) = getToken(MB.getBuffer(), " ");
|
2013-08-07 09:22:04 +08:00
|
|
|
PIDStr = PIDStr.substr(PIDStr.find_first_not_of(" "));
|
|
|
|
int PID;
|
2014-04-06 11:19:31 +08:00
|
|
|
if (!PIDStr.getAsInteger(10, PID)) {
|
|
|
|
auto Owner = std::make_pair(std::string(Hostname), PID);
|
|
|
|
if (processStillExecuting(Owner.first, Owner.second))
|
|
|
|
return Owner;
|
|
|
|
}
|
2012-01-30 04:15:10 +08:00
|
|
|
|
|
|
|
// Delete the lock file. It's invalid anyway.
|
2013-08-07 06:51:21 +08:00
|
|
|
sys::fs::remove(LockFileName);
|
2013-02-21 08:27:28 +08:00
|
|
|
return None;
|
2012-01-30 04:15:10 +08:00
|
|
|
}
|
|
|
|
|
2015-06-30 06:16:39 +08:00
|
|
|
static std::error_code getHostID(SmallVectorImpl<char> &HostID) {
|
|
|
|
HostID.clear();
|
|
|
|
|
|
|
|
#if USE_OSX_GETHOSTUUID
|
|
|
|
// On OS X, use the more stable hardware UUID instead of hostname.
|
|
|
|
struct timespec wait = {1, 0}; // 1 second.
|
|
|
|
uuid_t uuid;
|
|
|
|
if (gethostuuid(uuid, &wait) != 0)
|
|
|
|
return std::error_code(errno, std::system_category());
|
|
|
|
|
|
|
|
uuid_string_t UUIDStr;
|
|
|
|
uuid_unparse(uuid, UUIDStr);
|
|
|
|
StringRef UUIDRef(UUIDStr);
|
|
|
|
HostID.append(UUIDRef.begin(), UUIDRef.end());
|
|
|
|
|
|
|
|
#elif LLVM_ON_UNIX
|
|
|
|
char HostName[256];
|
|
|
|
HostName[255] = 0;
|
|
|
|
HostName[0] = 0;
|
|
|
|
gethostname(HostName, 255);
|
|
|
|
StringRef HostNameRef(HostName);
|
|
|
|
HostID.append(HostNameRef.begin(), HostNameRef.end());
|
|
|
|
|
|
|
|
#else
|
|
|
|
StringRef Dummy("localhost");
|
|
|
|
HostID.append(Dummy.begin(), Dummy.end());
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return std::error_code();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool LockFileManager::processStillExecuting(StringRef HostID, int PID) {
|
2012-09-04 17:14:45 +08:00
|
|
|
#if LLVM_ON_UNIX && !defined(__ANDROID__)
|
2015-06-30 06:16:39 +08:00
|
|
|
SmallString<256> StoredHostID;
|
|
|
|
if (getHostID(StoredHostID))
|
|
|
|
return true; // Conservatively assume it's executing on error.
|
|
|
|
|
2012-01-30 04:15:10 +08:00
|
|
|
// Check whether the process is dead. If so, we're done.
|
2015-06-30 06:16:39 +08:00
|
|
|
if (StoredHostID == HostID && getsid(PID) == -1 && errno == ESRCH)
|
2012-01-30 04:15:10 +08:00
|
|
|
return false;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
LTO: Keep file handles open for memory mapped files.
On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).
We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.
One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.
A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.
Differential Revision: https://reviews.llvm.org/D48051
llvm-svn: 334630
2018-06-14 02:03:14 +08:00
|
|
|
namespace {
|
|
|
|
|
|
|
|
/// An RAII helper object ensure that the unique lock file is removed.
|
|
|
|
///
|
|
|
|
/// Ensures that if there is an error or a signal before we finish acquiring the
|
|
|
|
/// lock, the unique file will be removed. And if we successfully take the lock,
|
|
|
|
/// the signal handler is left in place so that signals while the lock is held
|
|
|
|
/// will remove the unique lock file. The caller should ensure there is a
|
|
|
|
/// matching call to sys::DontRemoveFileOnSignal when the lock is released.
|
|
|
|
class RemoveUniqueLockFileOnSignal {
|
|
|
|
StringRef Filename;
|
|
|
|
bool RemoveImmediately;
|
|
|
|
public:
|
|
|
|
RemoveUniqueLockFileOnSignal(StringRef Name)
|
|
|
|
: Filename(Name), RemoveImmediately(true) {
|
|
|
|
sys::RemoveFileOnSignal(Filename, nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
~RemoveUniqueLockFileOnSignal() {
|
|
|
|
if (!RemoveImmediately) {
|
|
|
|
// Leave the signal handler enabled. It will be removed when the lock is
|
|
|
|
// released.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
sys::fs::remove(Filename);
|
|
|
|
sys::DontRemoveFileOnSignal(Filename);
|
|
|
|
}
|
|
|
|
|
|
|
|
void lockAcquired() { RemoveImmediately = false; }
|
|
|
|
};
|
|
|
|
|
|
|
|
} // end anonymous namespace
|
|
|
|
|
2012-01-30 04:15:10 +08:00
|
|
|
LockFileManager::LockFileManager(StringRef FileName)
|
|
|
|
{
|
2013-01-10 10:01:35 +08:00
|
|
|
this->FileName = FileName;
|
2014-06-13 10:24:39 +08:00
|
|
|
if (std::error_code EC = sys::fs::make_absolute(this->FileName)) {
|
2016-06-04 08:34:00 +08:00
|
|
|
std::string S("failed to obtain absolute path for ");
|
|
|
|
S.append(this->FileName.str());
|
|
|
|
setError(EC, S);
|
2014-03-22 05:45:07 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
LockFileName = this->FileName;
|
2012-01-30 04:15:10 +08:00
|
|
|
LockFileName += ".lock";
|
|
|
|
|
|
|
|
// If the lock file already exists, don't bother to try to create our own
|
|
|
|
// lock file; it won't work anyway. Just figure out who owns this lock file.
|
|
|
|
if ((Owner = readLockFile(LockFileName)))
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Create a lock file that is unique to this instance.
|
LTO: Keep file handles open for memory mapped files.
On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).
We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.
One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.
A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.
Differential Revision: https://reviews.llvm.org/D48051
llvm-svn: 334630
2018-06-14 02:03:14 +08:00
|
|
|
UniqueLockFileName = LockFileName;
|
|
|
|
UniqueLockFileName += "-%%%%%%%%";
|
|
|
|
int UniqueLockFileID;
|
|
|
|
if (std::error_code EC = sys::fs::createUniqueFile(
|
|
|
|
UniqueLockFileName, UniqueLockFileID, UniqueLockFileName)) {
|
|
|
|
std::string S("failed to create unique file ");
|
|
|
|
S.append(UniqueLockFileName.str());
|
2016-06-04 08:34:00 +08:00
|
|
|
setError(EC, S);
|
2012-01-30 04:15:10 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Write our process ID to our unique lock file.
|
|
|
|
{
|
2015-06-30 06:16:39 +08:00
|
|
|
SmallString<256> HostID;
|
|
|
|
if (auto EC = getHostID(HostID)) {
|
2016-06-04 08:34:00 +08:00
|
|
|
setError(EC, "failed to get host id");
|
2015-06-30 06:16:39 +08:00
|
|
|
return;
|
|
|
|
}
|
2015-06-30 05:56:03 +08:00
|
|
|
|
LTO: Keep file handles open for memory mapped files.
On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).
We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.
One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.
A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.
Differential Revision: https://reviews.llvm.org/D48051
llvm-svn: 334630
2018-06-14 02:03:14 +08:00
|
|
|
raw_fd_ostream Out(UniqueLockFileID, /*shouldClose=*/true);
|
2015-06-30 06:16:39 +08:00
|
|
|
Out << HostID << ' ';
|
2012-01-30 04:15:10 +08:00
|
|
|
#if LLVM_ON_UNIX
|
2015-06-30 06:16:39 +08:00
|
|
|
Out << getpid();
|
2012-01-30 04:15:10 +08:00
|
|
|
#else
|
2015-06-30 06:16:39 +08:00
|
|
|
Out << "1";
|
2012-01-30 04:15:10 +08:00
|
|
|
#endif
|
LTO: Keep file handles open for memory mapped files.
On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).
We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.
One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.
A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.
Differential Revision: https://reviews.llvm.org/D48051
llvm-svn: 334630
2018-06-14 02:03:14 +08:00
|
|
|
Out.close();
|
2012-01-30 04:15:10 +08:00
|
|
|
|
|
|
|
if (Out.has_error()) {
|
2017-10-24 09:26:22 +08:00
|
|
|
// We failed to write out PID, so report the error, remove the
|
2012-01-30 04:15:10 +08:00
|
|
|
// unique lock file, and fail.
|
2016-06-04 08:34:00 +08:00
|
|
|
std::string S("failed to write to ");
|
LTO: Keep file handles open for memory mapped files.
On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).
We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.
One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.
A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.
Differential Revision: https://reviews.llvm.org/D48051
llvm-svn: 334630
2018-06-14 02:03:14 +08:00
|
|
|
S.append(UniqueLockFileName.str());
|
2017-10-24 09:26:22 +08:00
|
|
|
setError(Out.error(), S);
|
LTO: Keep file handles open for memory mapped files.
On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).
We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.
One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.
A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.
Differential Revision: https://reviews.llvm.org/D48051
llvm-svn: 334630
2018-06-14 02:03:14 +08:00
|
|
|
sys::fs::remove(UniqueLockFileName);
|
2012-01-30 04:15:10 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
LTO: Keep file handles open for memory mapped files.
On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).
We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.
One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.
A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.
Differential Revision: https://reviews.llvm.org/D48051
llvm-svn: 334630
2018-06-14 02:03:14 +08:00
|
|
|
// Clean up the unique file on signal, which also releases the lock if it is
|
|
|
|
// held since the .lock symlink will point to a nonexistent file.
|
|
|
|
RemoveUniqueLockFileOnSignal RemoveUniqueFile(UniqueLockFileName);
|
|
|
|
|
2016-08-24 01:14:32 +08:00
|
|
|
while (true) {
|
2014-03-12 02:40:24 +08:00
|
|
|
// Create a link from the lock file name. If this succeeds, we're done.
|
2014-06-13 10:24:39 +08:00
|
|
|
std::error_code EC =
|
LTO: Keep file handles open for memory mapped files.
On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).
We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.
One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.
A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.
Differential Revision: https://reviews.llvm.org/D48051
llvm-svn: 334630
2018-06-14 02:03:14 +08:00
|
|
|
sys::fs::create_link(UniqueLockFileName, LockFileName);
|
2015-06-30 01:08:41 +08:00
|
|
|
if (!EC) {
|
LTO: Keep file handles open for memory mapped files.
On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).
We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.
One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.
A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.
Differential Revision: https://reviews.llvm.org/D48051
llvm-svn: 334630
2018-06-14 02:03:14 +08:00
|
|
|
RemoveUniqueFile.lockAcquired();
|
2014-03-07 04:53:58 +08:00
|
|
|
return;
|
2015-06-30 01:08:41 +08:00
|
|
|
}
|
2012-01-30 04:15:10 +08:00
|
|
|
|
2014-06-14 01:20:48 +08:00
|
|
|
if (EC != errc::file_exists) {
|
2016-06-04 08:34:00 +08:00
|
|
|
std::string S("failed to create link ");
|
|
|
|
raw_string_ostream OSS(S);
|
LTO: Keep file handles open for memory mapped files.
On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).
We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.
One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.
A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.
Differential Revision: https://reviews.llvm.org/D48051
llvm-svn: 334630
2018-06-14 02:03:14 +08:00
|
|
|
OSS << LockFileName.str() << " to " << UniqueLockFileName.str();
|
2016-06-04 08:34:00 +08:00
|
|
|
setError(EC, OSS.str());
|
2014-03-07 04:53:58 +08:00
|
|
|
return;
|
|
|
|
}
|
2012-01-30 04:15:10 +08:00
|
|
|
|
2014-03-07 04:53:58 +08:00
|
|
|
// Someone else managed to create the lock file first. Read the process ID
|
|
|
|
// from the lock file.
|
LTO: Keep file handles open for memory mapped files.
On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).
We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.
One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.
A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.
Differential Revision: https://reviews.llvm.org/D48051
llvm-svn: 334630
2018-06-14 02:03:14 +08:00
|
|
|
if ((Owner = readLockFile(LockFileName))) {
|
|
|
|
// Wipe out our unique lock file (it's useless now)
|
|
|
|
sys::fs::remove(UniqueLockFileName);
|
|
|
|
return;
|
|
|
|
}
|
2014-03-07 01:37:10 +08:00
|
|
|
|
2015-03-18 18:17:07 +08:00
|
|
|
if (!sys::fs::exists(LockFileName)) {
|
2014-03-07 04:53:58 +08:00
|
|
|
// The previous owner released the lock file before we could read it.
|
|
|
|
// Try to get ownership again.
|
|
|
|
continue;
|
|
|
|
}
|
2014-03-07 01:37:10 +08:00
|
|
|
|
2014-03-07 04:53:58 +08:00
|
|
|
// There is a lock file that nobody owns; try to clean it up and get
|
|
|
|
// ownership.
|
2015-03-18 18:17:07 +08:00
|
|
|
if ((EC = sys::fs::remove(LockFileName))) {
|
2016-06-04 08:34:00 +08:00
|
|
|
std::string S("failed to remove lockfile ");
|
LTO: Keep file handles open for memory mapped files.
On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).
We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.
One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.
A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.
Differential Revision: https://reviews.llvm.org/D48051
llvm-svn: 334630
2018-06-14 02:03:14 +08:00
|
|
|
S.append(UniqueLockFileName.str());
|
2016-06-04 08:34:00 +08:00
|
|
|
setError(EC, S);
|
2014-03-07 04:53:58 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2012-01-30 04:15:10 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
LockFileManager::LockFileState LockFileManager::getState() const {
|
|
|
|
if (Owner)
|
|
|
|
return LFS_Shared;
|
|
|
|
|
2017-11-14 07:32:19 +08:00
|
|
|
if (ErrorCode)
|
2012-01-30 04:15:10 +08:00
|
|
|
return LFS_Error;
|
|
|
|
|
|
|
|
return LFS_Owned;
|
|
|
|
}
|
|
|
|
|
2016-06-04 08:34:00 +08:00
|
|
|
std::string LockFileManager::getErrorMessage() const {
|
2017-11-14 07:32:19 +08:00
|
|
|
if (ErrorCode) {
|
2016-06-04 08:34:00 +08:00
|
|
|
std::string Str(ErrorDiagMsg);
|
2017-11-14 07:32:19 +08:00
|
|
|
std::string ErrCodeMsg = ErrorCode.message();
|
2016-06-04 08:34:00 +08:00
|
|
|
raw_string_ostream OSS(Str);
|
|
|
|
if (!ErrCodeMsg.empty())
|
2017-11-14 07:06:54 +08:00
|
|
|
OSS << ": " << ErrCodeMsg;
|
|
|
|
return OSS.str();
|
2016-06-04 08:34:00 +08:00
|
|
|
}
|
|
|
|
return "";
|
|
|
|
}
|
|
|
|
|
2012-01-30 04:15:10 +08:00
|
|
|
LockFileManager::~LockFileManager() {
|
|
|
|
if (getState() != LFS_Owned)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Since we own the lock, remove the lock file and our own unique lock file.
|
2015-03-18 18:17:07 +08:00
|
|
|
sys::fs::remove(LockFileName);
|
LTO: Keep file handles open for memory mapped files.
On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).
We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.
One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.
A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.
Differential Revision: https://reviews.llvm.org/D48051
llvm-svn: 334630
2018-06-14 02:03:14 +08:00
|
|
|
sys::fs::remove(UniqueLockFileName);
|
|
|
|
// The unique file is now gone, so remove it from the signal handler. This
|
|
|
|
// matches a sys::RemoveFileOnSignal() in LockFileManager().
|
|
|
|
sys::DontRemoveFileOnSignal(UniqueLockFileName);
|
2012-01-30 04:15:10 +08:00
|
|
|
}
|
|
|
|
|
2014-04-06 11:19:31 +08:00
|
|
|
LockFileManager::WaitForUnlockResult LockFileManager::waitForUnlock() {
|
2012-01-30 04:15:10 +08:00
|
|
|
if (getState() != LFS_Shared)
|
2014-04-06 11:19:31 +08:00
|
|
|
return Res_Success;
|
2012-01-30 04:15:10 +08:00
|
|
|
|
2018-08-23 17:42:58 +08:00
|
|
|
#ifdef _WIN32
|
2012-01-30 04:15:10 +08:00
|
|
|
unsigned long Interval = 1;
|
|
|
|
#else
|
|
|
|
struct timespec Interval;
|
|
|
|
Interval.tv_sec = 0;
|
|
|
|
Interval.tv_nsec = 1000000;
|
|
|
|
#endif
|
2017-03-18 08:32:34 +08:00
|
|
|
// Don't wait more than 40s per iteration. Total timeout for the file
|
|
|
|
// to appear is ~1.5 minutes.
|
|
|
|
const unsigned MaxSeconds = 40;
|
2012-01-30 04:15:10 +08:00
|
|
|
do {
|
|
|
|
// Sleep for the designated interval, to allow the owning process time to
|
|
|
|
// finish up and remove the lock file.
|
|
|
|
// FIXME: Should we hook in to system APIs to get a notification when the
|
|
|
|
// lock file is deleted?
|
2018-08-23 17:42:58 +08:00
|
|
|
#ifdef _WIN32
|
2012-01-30 04:15:10 +08:00
|
|
|
Sleep(Interval);
|
|
|
|
#else
|
2014-04-07 12:17:22 +08:00
|
|
|
nanosleep(&Interval, nullptr);
|
2012-01-30 04:15:10 +08:00
|
|
|
#endif
|
2013-04-06 04:53:57 +08:00
|
|
|
|
2015-02-20 02:22:35 +08:00
|
|
|
if (sys::fs::access(LockFileName.c_str(), sys::fs::AccessMode::Exist) ==
|
|
|
|
errc::no_such_file_or_directory) {
|
|
|
|
// If the original file wasn't created, somone thought the lock was dead.
|
2015-03-18 18:17:07 +08:00
|
|
|
if (!sys::fs::exists(FileName))
|
2015-02-20 02:22:35 +08:00
|
|
|
return Res_OwnerDied;
|
|
|
|
return Res_Success;
|
2013-01-10 10:01:35 +08:00
|
|
|
}
|
2013-04-06 04:53:57 +08:00
|
|
|
|
2015-02-20 02:22:35 +08:00
|
|
|
// If the process owning the lock died without cleaning up, just bail out.
|
|
|
|
if (!processStillExecuting((*Owner).first, (*Owner).second))
|
2014-04-06 11:19:31 +08:00
|
|
|
return Res_OwnerDied;
|
2012-01-30 04:15:10 +08:00
|
|
|
|
|
|
|
// Exponentially increase the time we wait for the lock to be removed.
|
2018-08-23 17:42:58 +08:00
|
|
|
#ifdef _WIN32
|
2012-01-30 04:15:10 +08:00
|
|
|
Interval *= 2;
|
|
|
|
#else
|
|
|
|
Interval.tv_sec *= 2;
|
|
|
|
Interval.tv_nsec *= 2;
|
|
|
|
if (Interval.tv_nsec >= 1000000000) {
|
|
|
|
++Interval.tv_sec;
|
|
|
|
Interval.tv_nsec -= 1000000000;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
} while (
|
2018-08-23 17:42:58 +08:00
|
|
|
#ifdef _WIN32
|
2012-01-30 04:15:10 +08:00
|
|
|
Interval < MaxSeconds * 1000
|
|
|
|
#else
|
|
|
|
Interval.tv_sec < (time_t)MaxSeconds
|
|
|
|
#endif
|
|
|
|
);
|
|
|
|
|
|
|
|
// Give up.
|
2014-04-06 11:19:31 +08:00
|
|
|
return Res_Timeout;
|
2012-01-30 04:15:10 +08:00
|
|
|
}
|
2015-02-10 04:34:24 +08:00
|
|
|
|
|
|
|
std::error_code LockFileManager::unsafeRemoveLockFile() {
|
2015-03-18 18:17:07 +08:00
|
|
|
return sys::fs::remove(LockFileName);
|
2015-02-10 04:34:24 +08:00
|
|
|
}
|