nondeterministic failure of allmydata.test.test_system.SystemTest.test_upload_and_download_{random_key,convergent} #1084
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#1084
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
(http://tahoe-lafs.org/buildbot/builders/FreeStorm%20CentOS5-i386/builds/17/steps/test/logs/stdio)
Test log here.
The code around that line is here.
This did not happen on a subsequent build with only this change.
Because there was an exception in the %d formatting of the message argument, we do not know what the value of
bytes_sent
was. It doesn't seem to have beenNone
because that would have produced a different error message:(but maybe there is a difference between Python 2.4.3 and 2.6.2 here.)
Replying to davidsarah:
There was; discount this argument.
bytes_sent
might have beenNone
.#1273 was probably a duplicate. That failure occurred on Windows Vista, so the problem is not specific to CentOS or the CentOS builder. The error message is not exactly the same (I think an assertion was added), but seems to be due to the same type error.
nondeterministic failure of allmydata.test.test_system.SystemTest.test_upload_and_download_random_key on CentOS builderto nondeterministic failure of allmydata.test.test_system.SystemTest.test_upload_and_download_random_keyIn http://tahoe-lafs.org/buildbot/builders/Arthur%20lenny%20c7%2032bit/builds/745/steps/test/logs/stdio , this problem happens for both
test_upload_and_download_random_key
andtest_upload_and_download_convergent
:nondeterministic failure of allmydata.test.test_system.SystemTest.test_upload_and_download_random_keyto nondeterministic failure of allmydata.test.test_system.SystemTest.test_upload_and_download_{random_key,convergent}Attachment Arthur-lenny-c7-32bit-build-745-test.txt (82202 bytes) added
Copy of http://tahoe-lafs.org/buildbot/builders/Arthur%20lenny%20c7%2032bit/builds/745/steps/test/logs/stdio/text
Attachment Arthur-lenny-c7-32bit-build-745-test.log.txt (455870 bytes) added
Copy of http://tahoe-lafs.org/buildbot/builders/Arthur%20lenny%20c7%2032bit/builds/745/steps/test/logs/test.log/text
A problem with similar characteristics happened just now on Ruben's Fedora buildslave:
failed:
http://tahoe-lafs.org/buildbot/builders/Ruben%20Fedora/builds/864
Ended with:
rebuilt exact same version and passed:
http://tahoe-lafs.org/buildbot/builders/Ruben%20Fedora/builds/865
I remember having a brainstorm that the
bytes_sent
would be None in the case that the helper had not been connected to the node before the node started its upload, so I hypothesized that there is a race condition in setting up the tests, between the node connecting to the helper and the node starting its upload.Not sure if that applies to this new issue from comment:78020. Also, I thought I wrote some notes about that last time, but they are not on this ticket. Is there a different (redundant) ticket somewhere? Did I post my notes elsewhere than trac? I will investigate...
comment:78020 looks like #846 to me. (It's in a different test method, but the error is almost identical to the one in http://tahoe-lafs.org/trac/tahoe-lafs/attachment/ticket/846/tahoe-846-test-fail.txt.)
I don't see any strong evidence that comment:78020 and #846 are the same bug as #1084 and #1273.