D5267: revlog: automatically read from opened file handles

indygreg (Gregory Szorc) phabricator at mercurial-scm.org
Tue Nov 13 20:41:29 UTC 2018


indygreg created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  The revlog reading code commonly opens a new file handle for
  reading on demand. There is support for passing a file handle
  to revlog.revision(). But it is marked as an internal argument.
  
  When revlogs are written, we write() data as it is available. But
  we don't flush() data until all revisions are written.
  
  Putting these two traits together, it is possible for an in-process
  revlog reader during active writes to trigger the opening of a new
  file handle on a file with unflushed writes. The reader won't have
  access to all "available" revlog data (as it hasn't been flushed).
  And with the introduction of the previous patch, this can lead to
  the revlog raising an error due to a partial read.
  
  I witnessed this behavior when applying changegroup data (via
  `hg pull`) before issue6006 was fixed via different means. Having
  this and the previous patch in play would have helped cause errors
  earlier rather than manifesting as hash verification failures.
  
  While this has been a long-standing issue, I believe the relatively
  new delta computation code has tickled it into being more common.
  This is because the new delta computation code will compute deltas
  in more scenarios. This can lead to revlog reading. While the delta
  computation code is probably supposed to reuse file handles, it
  appears it isn't doing so in all circumstances.
  
  But the issue runs deeper than that. Theoretically, any code can
  access revision data during revlog writes. It appears we were just
  getting lucky that it wasn't. (The "add revision callback" passed to
  addgroup() provides an avenue to do this.)
  
  If I changed the revlog's behavior to not cache the full revision
  text or to clear caches after revision insertion during addgroup(),
  I was able to produce crashes 100% of the time when writing changelog
  revisions. This is because changelog's add revision callback attempts
  to resolve the revision data to access the changed files list. And
  without the revision's fulltext being cached, we performed a revlog
  read, which required opening a new file handle. This attempted to read
  unflushed data, leading to a partial read and a crash.
  
  This commit teaches the revlog to store the file handles used for
  writing multiple revisions during addgroup(). It also teaches the
  code for resolving a file handle when reading to use these handles,
  if available. This ensures that *any* reads (regardless of their
  source) use the active writing file handles, if available. These
  file handles have access to the unflushed data because they wrote it.
  This allows reads to complete without issue.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D5267

AFFECTED FILES
  mercurial/revlog.py

CHANGE DETAILS

diff --git a/mercurial/revlog.py b/mercurial/revlog.py
--- a/mercurial/revlog.py
+++ b/mercurial/revlog.py
@@ -375,6 +375,9 @@
         # custom flags.
         self._flagprocessors = dict(_flagprocessors)
 
+        # 2-tuple of file handles being used for active writing.
+        self._writinghandles = None
+
         mmapindexthreshold = None
         v = REVLOG_DEFAULT_VERSION
         opts = getattr(opener, 'options', None)
@@ -505,8 +508,21 @@
     @contextlib.contextmanager
     def _datareadfp(self, existingfp=None):
         """file object suitable to read data"""
+        # Use explicit file handle, if given.
         if existingfp is not None:
             yield existingfp
+
+        # Use a file handle being actively used for writes, if available.
+        # There is some danger to doing this because reads will seek the
+        # file. However, _writeentry() performs a SEEK_END before all writes,
+        # so we should be safe.
+        elif self._writinghandles:
+            if self._inline:
+                yield self._writinghandles[0]
+            else:
+                yield self._writinghandles[1]
+
+        # Otherwise open a new file handle.
         else:
             if self._inline:
                 func = self._indexfp
@@ -1750,6 +1766,9 @@
         if fp:
             fp.flush()
             fp.close()
+            # We can't use the cached file handle after close(). So prevent
+            # its usage.
+            self._writinghandles = None
 
         with self._indexfp('r') as ifh, self._datafp('w') as dfh:
             for r in self:
@@ -1996,7 +2015,9 @@
         # if the file was seeked to before the end. See issue4943 for more.
         #
         # We work around this issue by inserting a seek() before writing.
-        # Note: This is likely not necessary on Python 3.
+        # Note: This is likely not necessary on Python 3. However, because
+        # the file handle is reused for reads and may be seeked there, we need
+        # to be careful before changing this.
         ifh.seek(0, os.SEEK_END)
         if dfh:
             dfh.seek(0, os.SEEK_END)
@@ -2029,6 +2050,9 @@
         this revlog and the node that was added.
         """
 
+        if self._writinghandles:
+            raise error.ProgrammingError('cannot nest addgroup() calls')
+
         nodes = []
 
         r = len(self)
@@ -2048,6 +2072,9 @@
             if dfh:
                 dfh.flush()
             ifh.flush()
+
+        self._writinghandles = (ifh, dfh)
+
         try:
             deltacomputer = deltautil.deltacomputer(self)
             # loop through our set of deltas
@@ -2109,7 +2136,10 @@
                     ifh.close()
                     dfh = self._datafp("a+")
                     ifh = self._indexfp("a+")
+                    self._writinghandles = (ifh, dfh)
         finally:
+            self._writinghandles = None
+
             if dfh:
                 dfh.close()
             ifh.close()



To: indygreg, #hg-reviewers
Cc: mercurial-devel


More information about the Mercurial-devel mailing list