id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
616	bug in repairer causes sporadic hangs in unit tests	zooko		"There is a bug in {{{DownUpConnector._satisfy_reads_if_possible()}}}:

[source:src/allmydata/immutable/repairer.py@20090112214120-e01fd-7d241072d30b14d3e243829e952e8c8440e6c461#L127]

It should be putting {{{leftover}}} bytes back into the {{{self.bufs}}} and the rest into the result, not putting all-but-{{{leftover}}} bytes back and the rest into the result!  In cases where the input chunks have come in different sizes than the read requests, this bug could lead to a read request getting more or fewer bytes than it requested.  This could lead to data corruption (although not irreversibly so -- it would then upload the same sequence of bytes but in different-sized blocks, which would screw up the integrity checking code but not the ciphertext).

Fortunately, in our current code, the writes and the read requests are always of the same sizes (the block size), so this doesn't happen in practice.  I've added an assertion in [changeset:c59940852b94ba45] just to make it fail safely if this were to happen in practice.  I have started writing unit tests for {{{DownUpConnector._satisfy_reads_if_possible()}}} -- it turns out that we need unit tests in addition to the functional tests that I already wrote: [source:src/allmydata/test/test_repairer.py].

This explains the sporadic ""lost progress"" failure in the functional tests.  Hm...  Could it also explain the ""lost progress"" behavior that Brian and I witnessed on the testgrid when this code was newly committed to trunk?  I hope not, because that would mean that I am wrong about the writes and reads always having the same sizes.  But I'm pretty sure I am right about that."	defect	closed	major	1.3.0	code-encoding	1.2.0	fixed		tahoe-dev@…