I believe this happens because in test_file_hash, several hasher tests run concurrently but use the same, overlapping temporary files. The files are briefly 0 bytes long, and so when multiple tests run concurrently, sometimes both files are 0 bytes and the hashes are unexpectedly equal.
e.g. the [227, 176, 196, 66, 152, 252, 28, 20, 154, 251, 244, 200, 153, 111, 185, 36, 39, 174, 65, 228, 100, 155, 147, 76, 164, 149, 153, 27, 120, 82, 184, 85] above equals e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 which is the SHA256 hash for empty input.
If you run the
test_file_hash_*
tests repeatedly on a Linux machine with 16 or more threads (fewer untested), you should quickly see test failures:I believe this happens because in test_file_hash, several hasher tests run concurrently but use the same, overlapping temporary files. The files are briefly 0 bytes long, and so when multiple tests run concurrently, sometimes both files are 0 bytes and the hashes are unexpectedly equal.
e.g. the
[227, 176, 196, 66, 152, 252, 28, 20, 154, 251, 244, 200, 153, 111, 185, 36, 39, 174, 65, 228, 100, 155, 147, 76, 164, 149, 153, 27, 120, 82, 184, 85]
above equalse3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
which is the SHA256 hash for empty input.