Fix out-of-bounds in Timsort #24
Merged
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.
It appears that Timsort implementation accesses memory out-of-bounds, as can be witnessed by enabling
vector +unsafechecksflag: https://travis-ci.org/Bodigrim/vector-algorithms/jobs/618361005#log-containerThe tricky part is that while the algorithm reads some memory garbage, the latter never makes way into the final result. That is why the bug remained unspotted for so long. In its essence
mergeLoandmergeHiexecute the following recursive function:As one can see,
iterreadsvec ! (-1), but never actually uses it, so the output remains correct. However, if you are unlucky,unsafeReadwill trigger a memory access violation.This PR is just a straightforward fix. I understand that it may lack some elegance, and I believe that in future Timsort implementation may benefit from more love. But at the moment I would appreciate a reasonably quick turnaround, because for certain inputs this bug causes a segfault in
polypackage, which may affect its downstream dependencies (CC @sdiehl @Multramate).