Patchwork [3,of,3,stable] tests: document probable bug in test-largefiles-update.t

login
register
mail settings
Submitter Augie Fackler
Date Jan. 30, 2017, 11:54 p.m.
Message ID <e1db62cfe471bc278697.1485820458@imladris.local>
Download mbox | patch
Permalink /patch/18284/
State Accepted
Headers show

Comments

Augie Fackler - Jan. 30, 2017, 11:54 p.m.
# HG changeset patch
# User Augie Fackler <augie@google.com>
# Date 1485817557 18000
#      Mon Jan 30 18:05:57 2017 -0500
# Branch stable
# Node ID e1db62cfe471bc278697d771bc68589acbff9171
# Parent  b4118549138f0872c218835d3ae10c9e70d867de
tests: document probable bug in test-largefiles-update.t

I don't really know what's going on here, so we should probably not
commit this patch, but my conclusion based on the analysis in earlier
patches is that the old use of --check was a defect. This also fails
2-3% of the time, as the code did before I moved the later call to
update to --clean.
Augie Fackler - Jan. 31, 2017, 1:36 a.m.
(+marmoute, martinvonz per irc chat, +kiilerix since you touched this area most recently)

> On Jan 30, 2017, at 6:54 PM, Augie Fackler <raf@durin42.com> wrote:
> 
> # HG changeset patch
> # User Augie Fackler <augie@google.com>
> # Date 1485817557 18000
> #      Mon Jan 30 18:05:57 2017 -0500
> # Branch stable
> # Node ID e1db62cfe471bc278697d771bc68589acbff9171
> # Parent  b4118549138f0872c218835d3ae10c9e70d867de
> tests: document probable bug in test-largefiles-update.t

This patch, not suitable for committing, demonstrates what I think is a weird largefiles bug. The test as written before this series fails (correctly, I think) 2% of the time (that is, it should fail 100% of the time, but due to a largefiles bug it does not). Patches 1 and 2 clarify the current situation and correct the defect in the test.

It seems like the defect (re-)exposed by patch 3 is slightly easier to observe under high load - on my workstation with -j10, I see it about 2% of the time. On gcc112 with -j150, I can reproduce it about 4% of the time. I sort of suspect a dirstate race, but I’m not familiar enough with our dirstate functionality to speak with any authority on that, or to even really have confidence on where I should be looking. I experimented with sleeps before and after this update call, but couldn’t make the problem better or worse, which I find baffling.

> 
> I don't really know what's going on here, so we should probably not
> commit this patch, but my conclusion based on the analysis in earlier
> patches is that the old use of --check was a defect. This also fails
> 2-3% of the time, as the code did before I moved the later call to
> update to --clean.
> 
> diff --git a/tests/test-largefiles-update.t b/tests/test-largefiles-update.t
> --- a/tests/test-largefiles-update.t
> +++ b/tests/test-largefiles-update.t
> @@ -705,6 +705,11 @@ the working context)
>   $ hg status -A --rev '.^1' large2
>   M large2
> 
> +Defect: this update *should* fail 100% of the time, because we already
> +*know* the dirstate is dirty. Experimentally, at the time of this
> +writing, the command only fails about 2% of the time.
> +  $ hg update --check --quiet 4
> +
> #else
> 
> Test that "hg status" against revisions other than parent ignores exec
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Patch

diff --git a/tests/test-largefiles-update.t b/tests/test-largefiles-update.t
--- a/tests/test-largefiles-update.t
+++ b/tests/test-largefiles-update.t
@@ -705,6 +705,11 @@  the working context)
   $ hg status -A --rev '.^1' large2
   M large2
 
+Defect: this update *should* fail 100% of the time, because we already
+*know* the dirstate is dirty. Experimentally, at the time of this
+writing, the command only fails about 2% of the time.
+  $ hg update --check --quiet 4
+
 #else
 
 Test that "hg status" against revisions other than parent ignores exec