Charts: Crash building iterator. Range requires lowerBound <= upperBound
- [ x] I’ve read, understood, and done my best to follow the *CONTRIBUTING guidelines.
What did you do?
Upgrade from 3.6.0 to 4.0.2
What happened ?
Most drawing of charts leads to a crash when building iterator in
extension BarLineScatterCandleBubbleRenderer.XBounds: Sequence
because Range requires lowerBound <= upperBound
let entryTo = dataSet.entryForXValue(high, closestToY: .nan, rounding: .up) is nil. It looks like the closest found is < endIndex in the dataset.
I use custom minimum and maximum axis values and visible range.
The same code was working perfectly in v3.6. I also tried to rollback to 3.6 as a temporary workaround but the project doesn’t compile anymore with XCode 13.3.
Charts Environment
Charts version/Branch/Commit Number: 4.0.2 Xcode version: 13.3 (13E113) Swift version: 5 Platform(s) running Charts: iOS macOS version running Xcode: 12.0.1 (21A559)
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 2
- Comments: 37 (2 by maintainers)
@FelixHerrmann I verified that the latest build from the master branch does fix the problem!
Sorry for the late answer, the latest version seems to work well on my side too.
This does appear to be a bug. It’s happening to me on a LineChartView with the following data points: (-3, 0) (-2, 0) (0, 0)
It only happens if I set the xMin and xMax values of the x axis (I’m setting them to -4 and 7). Some of the points are not rendered, and then if I zoom in a little and pan to the left, I hit this crash.
I’m not too familiar with the code, but it looks like the problem is in BarLineScatterCandleBubbleRenderer.XBounds.set(). I think it’s trying to figure out the range of indices of points to render, but if you’ve set the xMin and xMax to be even a little larger than the full range of the data (which seems to a reasonable thing to do) then the range is not calculated correctly.
(looking back in this thread, this is the same place in the code that @sebastienhannay identified also.)
Would love to get this resolved; I’m currently stuck on version 3.6 due to this bug! 😀
@PWrzesinski Glad I could be of any help 😊.
I mean as it roll back the new calculation of xbounds introduce in 4.0.0 to the one in 3.6. I guess there must be a reason why it changed that much between 3.6 and 4.0.x. Again this could probably solve my issue but it would probably be better to fix the new calculation method than rollback to the old one