Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VectorHelper::convertToBinBoundary segfault for empty input vector #12897

Closed
SimonHeybrock opened this issue Jun 22, 2015 · 1 comment
Closed
Assignees
Labels
Bug Issues and pull requests that are regressions or would be considered a bug by users (e.g. crashing)
Milestone

Comments

@SimonHeybrock
Copy link
Contributor

VectorHelper::convertToBinBoundary does not work for an empty input vector bin_centers. The segfault is probably caused by a signed/unsigned issue/underflow in the main loop of the function and out of bounds access of bin_centers.

I don't know if this is maybe intended behavior (i.e., empty vectors do not occur or are forbidden). If not, maybe return an empty vector bin_edges?

@SimonHeybrock SimonHeybrock added Bug Issues and pull requests that are regressions or would be considered a bug by users (e.g. crashing) Easy labels Jun 22, 2015
@SimonHeybrock
Copy link
Contributor Author

In addition to the size 0 problem: For input size 1 there is no error, but I think it uses potentially unitialized values. Not sure how to handle that.

SimonHeybrock added a commit that referenced this issue Jun 22, 2015
This is in principle also part of the fix for #4600.
SimonHeybrock added a commit that referenced this issue Jun 22, 2015
As fas as I understand there is no definite way to deal with a bin
center vectro of size 1 --- we cannot compute a bin width. However, the
current implementation is broken: it depends on unitialized values and
yields things like an upper bin edge that is smaller than the lower
edge.
This test test (somewhat) arbitrarily for a bin width of 1.
SimonHeybrock added a commit that referenced this issue Jun 22, 2015
The solution (setting bin width to 1.0) is admittedly arbitrary, but in
lack of more information it seems to be the only solution (apart from
throwing an exception).
@SimonHeybrock SimonHeybrock self-assigned this Jun 22, 2015
@martyngigg martyngigg added this to the Release 3.5 milestone Jun 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Issues and pull requests that are regressions or would be considered a bug by users (e.g. crashing)
Projects
None yet
Development

No branches or pull requests

2 participants