Fixed memory allocation issue when decoding CRAM.#357
Merged
Conversation
This bug has existed a long time, but is now more likely to trigger by 6d2810c due to making it more likely to overrun the buffer. The issue is caused by zero length sequences ("*") with a CIGAR alignment. A full bullet-proof fix will require more work to use the ...decode_block() codec variants, but this fixes the common case of length 0.
These are from Staden io_lib, which exposed the buffer overrun fixed in 1a050b4. The CRAMs have been made by a version of Cramtools-3.0.jar and are designed for interoperability testing.
Member
|
Thanks — merged with some additions. Did you notice this warning in the new tests? |
Contributor
Author
|
Actually no I didn't spot that - it was lost in the mass of output. It's caused by comparing to an older variant of the test ref seqs, although fortunately harmless. Thanks. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This bug has existed a long time, but is now more likely to triggered by 6d2810c due to making it more likely to overrun the buffer.
The issue is caused by zero length sequences ("*") with a CIGAR alignment. A full bullet-proof fix will require more work to use the ...decode_block() codec variants, but this fixes the common case of length 0.