Bug 5581 - fsmonitor can race with itself if another process invokes hg status while wlock is held
Summary: fsmonitor can race with itself if another process invokes hg status while wlo...
Status: RESOLVED FIXED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: fsmonitor (show other bugs)
Version: unspecified
Hardware: All All
: wish bug
Assignee: Bugzilla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-01 03:18 UTC by Siddharth Agarwal
Modified: 2017-10-15 00:00 UTC (History)
1 user (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Siddharth Agarwal 2017-06-01 03:18 UTC
$ cat >> $HGRCPATH << EOF
  > [extensions]
  > fsmonitor =
  > rebase =
  > EOF

  $ hg init repo
  $ cd repo
  $ echo c0 >> a
  $ echo c0 >> b
  $ hg add a b
  $ hg ci -m c0
  $ echo c1 >> a
  $ hg ci -m c1
  $ hg up .^
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ echo c2 >> a
  $ echo c2 >> b
  $ hg ci -m c2
  created new head

Merge tool that runs status in between, triggering the race.

  $ cat >> $TESTTMP/mergetool.sh << EOF
  > echo "custom merge tool"
  > printf "c0\nc1\nc2\n" > \$1
  > hg --cwd $TESTTMP/repo status
  > EOF

  $ cat >> $HGRCPATH << EOF
  > [merge-tools]
  > test.executable=sh
  > test.args=$TESTTMP/mergetool.sh \$output
  > EOF

  $ hg rebase -s . -d 1 --tool test
  $ hg log -p --debug
  $ hg status

That last 'hg status' should be empty, but it returns 'M b'.
Comment 1 Siddharth Agarwal 2017-06-01 03:44 UTC
Note that reproducing this on default requires applying 'match: introduce nevermatcher for when no ignore files are present', which I've sent to the mailing list.
Comment 2 Siddharth Agarwal 2017-06-01 18:21 UTC
Closely related to bug 5584.
Comment 4 Bugzilla 2017-06-22 00:00 UTC
Bug was set to TESTING for 7 days, resolving
Comment 5 HG Bot 2017-10-04 17:44 UTC
Fixed by https://mercurial-scm.org/repo/hg/rev/2083d1643d69
Siddharth Agarwal <sid0@fb.com>
workingctx: add a way for extensions to run code at status fixup time

Some extensions like fsmonitor need to run code after dirstate.status is
called, but while the wlock is held. The extensions could grab the wlock again,
but that has its own peculiar race issues. For example, fsmonitor would not
like its state to be written out if the dirstate has changed underneath (see
issue5581 for what can go wrong in that sort of case).

To protect against these sorts of issues, allow extensions to declare that they
would like to run some code to run at fixup time.

fsmonitor will switch to using this in the next patch in the series.

(please test the fix)
Comment 6 Bugzilla 2017-10-15 00:00 UTC
Bug was set to TESTING for 10 days, resolving