Fix out-of-bounds access in bland::compute_broadcast_shape() - #32
Open
daniestevez wants to merge 1 commit into
Open
daniestevez wants to merge 1 commit into
daniestevez wants to merge 1 commit into
Conversation
The bland::compute_broadcast_shape() function is not implemented correctly and can perform out of bound accesses for some inputs, which can lead to aborts depending on the C++ library. In particular, I ran into this problem under Arch Linux when running bliss_find_hits with the single_coarse_guppi_59046_80036_DIAG_VOYAGER-1_0011.rawspec.0000.h5 example file. According to the backtrace, the crash happens during bliss:normalize(), which calls to bland::divide(). The problem is that compute_broadcast_shape() greedily consumes elements from shape by incrementing input_shape_index whenever the current components of shape and out_shape are equal or the current component of shape is 1. The following inputs all lead to out of bound accesses on shape: - shape = [1], out_shape = [10, 1024] - shape = [10], out_shape = [10, 1024] I had Claude debugging this problem, and it said that Numpy-style broadcasting (which is most likely what is intended here) works by right aligning both shapes and implicitly padding with ones on the left when needed, it suggested the following simpler implementation, which simply obtains broadcast_shape by padding shape on the left with ones to make its length equal to out_shape.size(). However, some more thought is probably needed about what is the API contract for this broadcast_shape() function. That is, what inputs are acceptable. For instance, what Claude suggested does not treat correctly the case out_shape.size() < shape.size(), because then offset is negative and we also run into out of bounds accesses. Someone with more knowledge of bliss should take a closer look at this. All I can say for now is that this patch allowed me to run bliss correctly with the Voyager test data, and with other data files, in my Arch Linux system.
Author
|
For more context, this is the crash I was running into I was using This is the gdb backtrace I also tried building bliss in Debug mode, and by doing that it is possible to see which inputs cause the crash in |
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
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.
The
bland::compute_broadcast_shape()function is not implemented correctly and can perform out of bound accesses for some inputs, which can lead to aborts depending on the C++ library. In particular, I ran into this problem under Arch Linux when runningbliss_find_hitswith thesingle_coarse_guppi_59046_80036_DIAG_VOYAGER-1_0011.rawspec.0000.h5example file. According to the backtrace, the crash happens duringbliss:normalize(), which calls tobland::divide().The problem is that
compute_broadcast_shape()greedily consumes elements fromshapeby incrementinginput_shape_indexwhenever the current components ofshapeandout_shapeare equal or the current component ofshapeis 1. The following inputs all lead to out of bound accesses on shape:I had Claude debugging this problem, and it said that Numpy-style broadcasting (which is most likely what is intended here) works by right aligning both shapes and implicitly padding with ones on the left when needed, it suggested the following simpler implementation, which simply obtains
broadcast_shapeby padding shape on the left with ones to make its length equal toout_shape.size().However, some more thought is probably needed about what is the API contract for this
broadcast_shape()function. That is, what inputs are acceptable. For instance, what Claude suggested does not treat correctly the caseout_shape.size() < shape.size(), because thenoffsetis negative and we also run into out of bounds accesses. Someone with more knowledge of bliss should take a closer look at this.All I can say for now is that this patch allowed me to run bliss correctly with the Voyager test data, and with other data files, in my Arch Linux system.