tahoe-lafs/trac-2024-07-25

test_vdrive fails on Solaris #144

New issue

Closed

opened 2007-09-22 16:45:58 +00:00 by zooko · 2 comments

zooko commented

2007-09-22 16:45:58 +00:00

Owner

On my GNU/OpenSolaris box ("nooxie"), I usually but not always get this unit test failure:

[FAIL]: allmydata.test.test_system.SystemTest.test_vdrive

Traceback (most recent call last):
  File "/home/zooko/playground/allmydata/tahoe/src/allmydata/test/test_system.py", line 646, in _test_runner
    self.failUnless("size: %d\n" % len(self.data) in output, "%s not in %s" % (len(self.data), output,))
twisted.trial.unittest.FailTest: 112 not in                size: 1500000
       num_segments: 2
       segment_size: 1048578
      needed_shares: 3
       total_shares: 10

         codec_name: crs
       codec_params: 1048578-3-10
  tail_codec_params: 451422-3-10

     plaintext_hash: cqutmpzodq7c7gjdhgh49szcyfnd5mekh4hg6y3ixt4t9yhfsedo
plaintext_root_hash: 7ubp3sz4b6eanbsupiq6msq1ctr6paczxyb7d371afborokjohwy
     crypttext_hash: ixnrjto993xepgu9h39th169rou7zxrjn3sdhusxwfih7bszbexy
crypttext_root_hash: uyezsmdtqooju48s7qfonzsdph4gykn6aui4gtmejoum45dn3z4y
    share_root_hash: f6iccmhg67133akxswcayq57wxb31oy6rjit5cuejjwue4kx745o

Size of data within the share:
               data: 500000
      uri-extension: 436
         validation: 458
Lease #0: owner=0, expire in 2678397s (30 days)

On my GNU/OpenSolaris box ("nooxie"), I usually but not always get this unit test failure: ``` [FAIL]: allmydata.test.test_system.SystemTest.test_vdrive Traceback (most recent call last): File "/home/zooko/playground/allmydata/tahoe/src/allmydata/test/test_system.py", line 646, in _test_runner self.failUnless("size: %d\n" % len(self.data) in output, "%s not in %s" % (len(self.data), output,)) twisted.trial.unittest.FailTest: 112 not in size: 1500000 num_segments: 2 segment_size: 1048578 needed_shares: 3 total_shares: 10 codec_name: crs codec_params: 1048578-3-10 tail_codec_params: 451422-3-10 plaintext_hash: cqutmpzodq7c7gjdhgh49szcyfnd5mekh4hg6y3ixt4t9yhfsedo plaintext_root_hash: 7ubp3sz4b6eanbsupiq6msq1ctr6paczxyb7d371afborokjohwy crypttext_hash: ixnrjto993xepgu9h39th169rou7zxrjn3sdhusxwfih7bszbexy crypttext_root_hash: uyezsmdtqooju48s7qfonzsdph4gykn6aui4gtmejoum45dn3z4y share_root_hash: f6iccmhg67133akxswcayq57wxb31oy6rjit5cuejjwue4kx745o Size of data within the share: data: 500000 uri-extension: 436 validation: 458 Lease #0: owner=0, expire in 2678397s (30 days) ```

tahoe-lafs added the

labels 2007-09-22 16:45:58 +00:00

tahoe-lafs added this to the 0.6.0 milestone 2007-09-22 16:45:58 +00:00

zooko commented

2007-09-22 21:26:47 +00:00

Author

Owner

fixed by changeset:a18f7aa6d5771d9a

tahoe-lafs added the

fixed

label 2007-09-22 21:26:47 +00:00

zooko closed this issue

2007-09-22 21:26:47 +00:00

warner commented

2007-09-28 02:26:13 +00:00

Author

Owner

and fixed even better by changeset:9b09fd3bf1993233. The problem was that the test depended upon
os.walk returning share files in a particular order, and Solaris happened to
return them in a different order than the other platforms. The fix was to
make sure that we only have one file in the mesh when we run that test (and
thus look for those share files), to remove the uncertainty.

Just wanted to make it clear why this appeared to be a solaris-specific
problem..

and fixed even better by changeset:9b09fd3bf1993233. The problem was that the test depended upon os.walk returning share files in a particular order, and Solaris happened to return them in a different order than the other platforms. The fix was to make sure that we only have one file in the mesh when we run that test (and thus look for those share files), to remove the uncertainty. Just wanted to make it clear why this appeared to be a solaris-specific problem..

tahoe-lafs added

code

and removed

unknown

labels 2007-09-28 02:26:13 +00:00