On Wed, 2 Jan 2019 23:40:11 +0100, Boris FELD wrote: > On 04/12/2018 12:09, Yuya Nishihara wrote: > > On Sun, 02 Dec 2018 17:17:43 +0100, Boris Feld wrote: > >> # HG changeset patch > >> # User Boris Feld <boris.f...@octobus.net> > >> # Date 1542949784 -3600 > >> # Fri Nov 23 06:09:44 2018 +0100 > >> # Node ID 9708243274585f9544c70925eb0b0fa0ec7aba4f > >> # Parent 0fff68dfbe48d87dce8b8736c0347ed5aa79030e > >> # EXP-Topic mmap > >> # Available At https://bitbucket.org/octobus/mercurial-devel/ > >> # hg pull https://bitbucket.org/octobus/mercurial-devel/ -r > >> 970824327458 > >> mmapindex: set default to 1MB > > Can you check if strip/rollback properly copy the revlog before truncating > > it? > > > > If a mmapped revlog is truncated by another process, the mapped memory > > could be > > invalid. The worst case, the process would be killed by SIGBUS. > > Hum good catch, process reading a repository being stripped have always > been up for troubles. However, mmap makes it worse by raising a signal > instead of just having wonky seek. It also introduces new cases where > this can happen.
mmap isn't worse because of SIGBUS, but because the index data can be updated after the index length is determined. Before, a single in-memory revlog index was at least consistent. > What shall we do here, I guess our best bet is to intercept these SIGBUS > when reading revlog index? I don't think it'll be easy to handle SIGBUS properly. And SIGBUS won't always be raised. Perhaps, the easiest solution is to copy the revlog index before strip/rollback. IIRC, the mmap implementation was highly experimental. I don't know if it's widely tested other than in FB where strip is never used. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
