Skip to content

Commit 0ede728

Browse files
committed
[Serialization] Add more context to why we load swiftmodule files as volatile
1 parent a4becda commit 0ede728

File tree

1 file changed

+10
-0
lines changed

1 file changed

+10
-0
lines changed

lib/Serialization/SerializedModuleLoader.cpp

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -351,6 +351,16 @@ std::error_code SerializedModuleLoaderBase::openModuleFile(
351351
// Use the default arguments except for IsVolatile. Force avoiding the use of
352352
// mmap to workaround issues on NFS when the swiftmodule file loaded changes
353353
// on disk while it's in use.
354+
//
355+
// In practice, a swiftmodule file can chane when a client uses a
356+
// swiftmodule file from a framework while the framework is recompiled and
357+
// installed over existing files. Or when many processes rebuild the same
358+
// module interface.
359+
//
360+
// We have seen these scenarios leading to deserialization errors that on
361+
// the surface look like memory corruption.
362+
//
363+
// rdar://63755989
354364
llvm::ErrorOr<std::unique_ptr<llvm::MemoryBuffer>> ModuleOrErr =
355365
FS.getBufferForFile(ModulePath,
356366
/*FileSize=*/-1,

0 commit comments

Comments
 (0)