In an attempt to fix memory leaks during encode of malformed CRAM data, that lead to bailing out early, we attempted to get everything to a uniform state as soon as possible. Specifically s->aux_blocks get migrated to s->blocks earlier, so if we bail out we don't have the decision to make as to which bit of memory needs freeing.
That worked, but unfortunately I forgot that the compression is applied to s->aux_blocks and not s->blocks for auxiliary tags, so moving the blocks earlier gives uncompressed blocks in CRAM. The format is valid and all tests pass, but it's overly large for obvious reasons.
Sadly this is a rather serious bug caused by an attempt to fix a really minor bug.
In an attempt to fix memory leaks during encode of malformed CRAM data, that lead to bailing out early, we attempted to get everything to a uniform state as soon as possible. Specifically s->aux_blocks get migrated to s->blocks earlier, so if we bail out we don't have the decision to make as to which bit of memory needs freeing.
That worked, but unfortunately I forgot that the compression is applied to s->aux_blocks and not s->blocks for auxiliary tags, so moving the blocks earlier gives uncompressed blocks in CRAM. The format is valid and all tests pass, but it's overly large for obvious reasons.
Sadly this is a rather serious bug caused by an attempt to fix a really minor bug.
Fixes samtools/samtools#1968