46bcc3661 changed the memory block realloc from growing by size1.5 to size1.25, but neither are correct when the original size is very small. Specifically the hts-specs test/cram/3.0/passed/1002_qual.cram file calls block_resize with b->alloc=2. Doing *1.25 on this gives us 2 still due to integer rounding, and so an infinite loop occurs.
It never assumed we'd start with such a small block and it attempts to leap from size 0 to size 1024, but obviously allocating its own blocks to exact sizes and bypassing this initial block growth check.
Refactored the code so to remove the loop, remove the ?: for size 0, and generally just smarten it up a bit.
Tested on Illumina, Ultima Genomics and Oxford Nanopore files and it's no worse on speed / memory to before, and sometimes 2-3% quicker or smaller.
46bcc3661 changed the memory block realloc from growing by size1.5 to size1.25, but neither are correct when the original size is very small. Specifically the hts-specs test/cram/3.0/passed/1002_qual.cram file calls block_resize with b->alloc=2. Doing *1.25 on this gives us 2 still due to integer rounding, and so an infinite loop occurs.
It never assumed we'd start with such a small block and it attempts to leap from size 0 to size 1024, but obviously allocating its own blocks to exact sizes and bypassing this initial block growth check.
Refactored the code so to remove the loop, remove the ?: for size 0, and generally just smarten it up a bit.
Tested on Illumina, Ultima Genomics and Oxford Nanopore files and it's no worse on speed / memory to before, and sometimes 2-3% quicker or smaller.
Bug reported by Sebastian Deorowicz