This issue became apparent when the readFloats method in Bits.java started throwing Socket timeouts after ReadDB was set up on a new data server (and after a move to Java 11). Upon investigation, the bug was only happening when bytesLeftover was non zero and when only a few bytes remained to be read from the stream (typically less than 4). It turned out that both readInts() and readFloats() had lines as follows to calculate how many bytes to read from the stream:

int toread = Math.min(((count - outputpos) * 4), buffer.length - bytesLeftover);

This did not account for a non-zero bytesLeftover value. The lines should have been:

int toread = Math.min(((count - outputpos) * 4)-bytesLeftover, buffer.length - bytesLeftover);
(fixed now)

The effect of this bug was that readInts was occassionally reading too many bytes from the stream, reading into the bytes sent by sendFloats by the relevant ServerTask. This left too few bytes for readFloats(). The data read by readFloats was probably nonsense too.

Why didn't we notice this before?
It seems like this was only an issue in situations where bytesLeftover was non-zero, and that seems to mostly happen when the Client is reading data faster than the ServerTask can send it. The new data server has low latency, so this may be why we only noticed it now (note that the bug was not occurring as frequently from a home connection). Furthermore, the buffer on ServerTask was mistakenly hardcoded as 8192 bytes, whereas the Client had a buffer size of 8192*16. Thus, this also contributed to the Client reading faster than ServerTask was writing.

I don't think this issue would have contributed to erroneous analyses, unless folks were ignoring Socket timeout errors.

1-based coordinates should be end - start + 1 when computing fragment
length

This file loader fetch both reads of a pair to determine 5' position, it
avoids the issue that we couldn't infer CIGAR string of read2 given only
read1 in SAMFileHitLoader

There was a bug where the if clause for SAM/BAM was not connected to everything else