spurious test failure due to race condition in allmydata.test.test_cli.Cp.test_copy_using_filecap #936

Closed
opened 2010-02-03 23:17:06 +00:00 by davidsarah · 10 comments
davidsarah commented 2010-02-03 23:17:06 +00:00
Owner

Reported by Ludovic Courtès,

http://hydra.nixos.org/build/278961/nixlog/14/raw :

allmydata.test.test_cli.Cp.test_copy_using_filecap fails with

allmydata.scripts.common.UnknownAliasError: Unknown alias 'tahoe', please create it with 'tahoe add-alias' or 'tahoe create-alias'.

I think this is because the test creates the "tahoe" alias (line 1000), but does not chain subsequent operations to the resulting Deferred. So, the alias might not have been created by the time it is needed.

Reported by Ludovic Courtès, <http://hydra.nixos.org/build/278961/nixlog/14/raw> : allmydata.test.test_cli.Cp.test_copy_using_filecap fails with ``` allmydata.scripts.common.UnknownAliasError: Unknown alias 'tahoe', please create it with 'tahoe add-alias' or 'tahoe create-alias'. ``` I think this is because the test creates the "tahoe" alias (line 1000), but does not chain subsequent operations to the resulting Deferred. So, the alias *might* not have been created by the time it is needed.
tahoe-lafs added the
code-frontend-cli
major
defect
1.5.0
labels 2010-02-03 23:17:06 +00:00
tahoe-lafs added this to the 1.7.0 milestone 2010-02-03 23:17:06 +00:00
davidsarah commented 2010-02-03 23:20:54 +00:00
Author
Owner

Attachment fix-test-copy-using-filecap-darcspatch.txt (50851 bytes) added

Fix race condition in allmydata.test.test_cli.Cp.test_copy_using_filecap

**Attachment** fix-test-copy-using-filecap-darcspatch.txt (50851 bytes) added Fix race condition in allmydata.test.test_cli.Cp.test_copy_using_filecap
davidsarah commented 2010-02-03 23:25:52 +00:00
Author
Owner

Attachment fix-test-copy-using-filecap-diff.txt (1077 bytes) added

Same thing as a unified diff

**Attachment** fix-test-copy-using-filecap-diff.txt (1077 bytes) added Same thing as a unified diff
warner commented 2010-02-05 04:07:13 +00:00
Author
Owner

looks good. do_cli() definitely needs to be waited upon, since it uses deferToThread(). All sorts of nasty race conditions if that Deferred is ignored.

I would advise also changing the open(fn1, "wb").write(DATA1) at line 15 to explicitly close the filehandle. The file object is not obligated to flush anything until it gets GC'ed, and merely going out of scope is not enough to force that. (in practice I've never seen it behave otherwise, but that probably depends on the platform). Unfortunately the full approach is a bit verbose:

f = open(fn1, "wb")
f.write(...)
f.close()
looks good. `do_cli()` definitely needs to be waited upon, since it uses `deferToThread()`. All sorts of nasty race conditions if that Deferred is ignored. I would advise also changing the `open(fn1, "wb").write(DATA1)` at line 15 to explicitly close the filehandle. The file object is not obligated to flush anything until it gets GC'ed, and merely going out of scope is not enough to force that. (in practice I've never seen it behave otherwise, but that probably depends on the platform). Unfortunately the full approach is a bit verbose: ``` f = open(fn1, "wb") f.write(...) f.close() ```
davidsarah commented 2010-02-05 18:36:11 +00:00
Author
Owner

Attachment fix-test-copy-using-filecap-2-darcspatch.txt (53375 bytes) added

Fix race conditions in allmydata.test.test_cli.Cp.test_copy_using_filecap, and minor cleanup

**Attachment** fix-test-copy-using-filecap-2-darcspatch.txt (53375 bytes) added Fix race conditions in allmydata.test.test_cli.Cp.test_copy_using_filecap, and minor cleanup
davidsarah commented 2010-02-05 20:13:05 +00:00
Author
Owner

Assigning to Brian for review.

Assigning to Brian for review.
davidsarah commented 2010-02-06 01:45:58 +00:00
Author
Owner

Attachment fix-test-cli-darcspatch.txt (65072 bytes) added

Previous attachment was missing some of my changes.

**Attachment** fix-test-cli-darcspatch.txt (65072 bytes) added Previous attachment was missing some of my changes.
davidsarah commented 2010-02-06 01:49:53 +00:00
Author
Owner

Hmm, trac seems to have deleted the description of the patch. It was:

  • fix race conditions and missing callback in allmydata.test.test_cli.Cp.test_copy_using_filecap,
  • add utilities for one-liner reading and writing of files,
  • fix cases in test_cli where files were not being closed after writing.
  • (in separate patch), refactor test_cli to use the new utilities in other places.

Note: this now opens files in binary mode where they previously opened in text mode, but I believe that's correct.

The missing callback was _copy_file in test_copy_using_filecap, which led to some of the intended checks in that test not being performed.

Hmm, trac seems to have deleted the description of the patch. It was: * fix race conditions and missing callback in `allmydata.test.test_cli.Cp.test_copy_using_filecap`, * add utilities for one-liner reading and writing of files, * fix cases in test_cli where files were not being closed after writing. * (in separate patch), refactor test_cli to use the new utilities in other places. Note: this now opens files in binary mode where they previously opened in text mode, but I believe that's correct. The missing callback was `_copy_file` in `test_copy_using_filecap`, which led to some of the intended checks in that test not being performed.
davidsarah commented 2010-02-06 01:55:50 +00:00
Author
Owner

Replying to warner:

The file object is not obligated to flush anything until it gets GC'ed, and merely going out of scope is not enough to force that. (in practice I've never seen it behave otherwise, but that probably depends on the platform).

I believe it will always behave that way in CPython (due to its use of reference counting), but not in other Python implementations.

Replying to [warner](/tahoe-lafs/trac-2024-07-25/issues/936#issuecomment-116844): > The file object is not obligated to flush anything until it gets GC'ed, and merely going out of scope is not enough to force that. (in practice I've never seen it behave otherwise, but that probably depends on the platform). I believe it will always behave that way in CPython (due to its use of reference counting), but not in other Python implementations.
tahoe-lafs modified the milestone from 1.7.0 to 1.6.1 2010-02-15 20:21:54 +00:00
zooko commented 2010-02-21 06:00:22 +00:00
Author
Owner

I reviewed this patch and it looks right to me. One tiny detail is that the one-liner read and write functions in [the copy of fileutil in tahoe-lafs]source:src/allmydata/util/fileutil.py are syntactically different from those same functions in the copy of fileutil in pyutil which is too bad because it means more diffs next time I manually merge those files. (See #47 (use pyutil as a separate package and contribute src/allmydata/util/* into pyutil).)

I will apply this patch.

I reviewed this patch and it looks right to me. One tiny detail is that the one-liner read and write functions in [the copy of fileutil in tahoe-lafs]source:src/allmydata/util/fileutil.py are syntactically different from [those same functions in the copy of fileutil in pyutil](http://allmydata.org/trac/pyutil/browser/pyutil/pyutil/fileutil.py?rev=167#L19) which is too bad because it means more diffs next time I manually merge those files. (See #47 (use pyutil as a separate package and contribute src/allmydata/util/* into pyutil).) I will apply this patch.
zooko commented 2010-02-21 06:20:31 +00:00
Author
Owner

fixed by changeset:c984a09fe769ba4f and changeset:85a50feeaa0a6150. Thanks!

fixed by changeset:c984a09fe769ba4f and changeset:85a50feeaa0a6150. Thanks!
tahoe-lafs added the
fixed
label 2010-02-21 06:20:38 +00:00
zooko closed this issue 2010-02-21 06:20:38 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#936
No description provided.