Crash under iOS 7 with SChartColumnSeries' stackIndex property


#1

Code that worked previously is now causing a crash for me under ShinobiCharts for iOS 7. I’m attempting to use SChartColumnSeries’ stackIndex property to render 3 series ontop of each other, but the code is now causing a crash using the latest version of ShinobiCharts. 

Am I missing something obvious?

***Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM objectAtIndex:]: index 1 beyond bounds [0 .. 0]'
*** First throw call stack:
(
	0 CoreFoundation 0x0464c5e4 __exceptionPreprocess + 180
	1 libobjc.A.dylib 0x0315d8b6 objc_exception_throw + 44
	2 CoreFoundation 0x045ed4e6 -[__NSArrayM objectAtIndex:] + 246
	3 Diabetik 0x0016b6f2 -[SChartBarColumnSeries drawBin:withDrawer:withGLBaseline:andGLTranslation:currentRenderIndexDict:] + 1323
	4 Diabetik 0x001aaccc -[SChartCartesianSeries drawWithDrawer:withGLBaseline:andGLTranslation:] + 537
	5 Diabetik 0x001b351d -[SChartSeriesGroup drawSingleSeries:onChart:] + 242
	6 Diabetik 0x001b35d6 -[SChartSeriesGroup drawStackedSeries:onChart:] + 108
	7 Diabetik 0x001b3978 -[SChartSeriesGroup drawSeriesOnChart:] + 914
	8 Diabetik 0x00191871 -[SChartCanvas drawChart:] + 1465
	9 Diabetik 0x0018d7cb -[SChartCanvasRenderView drawRect:] + 64
	10 UIKit 0x01bd3d56 -[UIView(CALayerDelegate) drawLayer:inContext:] + 504
	11 QuartzCore 0x019cedc9 -[CALayer drawInContext:] + 123
	12 QuartzCore 0x019ce77e _ZN2CA5Layer8display_Ev + 624
	13 QuartzCore 0x019ced49 -[CALayer _display] + 33
	14 QuartzCore 0x019ce506 _ZN2CA5Layer7displayEv + 144
	15 QuartzCore 0x019ced23 -[CALayer display] + 33
	16 QuartzCore 0x019c2ed3 _ZN2CA5Layer17display_if_neededEPNS_11TransactionE + 323
	17 QuartzCore 0x019c2f4c _ZN2CA5Layer28layout_and_display_if_neededEPNS_11TransactionE + 38
	18 QuartzCore 0x0192aae6 _ZN2CA7Context18commit_transactionEPNS_11TransactionE + 294
	19 QuartzCore 0x0192be71 _ZN2CA11Transaction6commitEv + 393
	20 QuartzCore 0x0192c544 _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv + 92
	21 CoreFoundation 0x046144ce __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30
	22 CoreFoundation 0x0461441f __CFRunLoopDoObservers + 399
	23 CoreFoundation 0x045f2344 __CFRunLoopRun + 1076
	24 CoreFoundation 0x045f1ac3 CFRunLoopRunSpecific + 467
	25 CoreFoundation 0x045f18db CFRunLoopRunInMode + 123
	26 GraphicsServices 0x04ddf9e2 GSEventRunModal + 192
	27 GraphicsServices 0x04ddf809 GSEventRun + 104
	28 UIKit 0x01b69d3b UIApplicationMain + 1225
	29 Diabetik 0x0000ac2d main + 141
	30 libdyld.dylib 0x0367470d start + 1
)

#2

Hi Nial,

We’ve already discussed this via the support channel, but I figured it might be useful to post up to the forum as well just in case it is of use to other people.

The cause of this issue is that we changed how our stacking algorithm worked. We did this for the release of charts in September. If you are stacking series, you now need to ensure that the x values of your series (or y values for vertical series) are in ascending order. The crash you are seeing here is due to your data being passed in with data values in descending order, which our stacking algorithm doesn’t handle.

I think there is an issue here that we didn’t communicate this well enough to our customer base when we made this change. We did update our API documentation, but it is clear that that wasn’t enough. We also need to improve the error message which we display in this case, to make it clearer what the cause of the error is. We shall address that in a future release.

In the meantime, the key point to take away here is that the chart now requires series to contain ordered data if you are stacking series. I hope this is of use to any people reading this.

Have a great Christmas,

Dan


#3

Bumping this thread; thought to make a new post but this is too relevant.

I am having a similar issue, with a little bit different of a stack trace. I already tried ordering my data points in ascending order of value (which is perhaps a different series ordering for every bar of data). It works if I trim my data array to 13 sets of data or less, but once I let it go to 14 or higher (no matter what items are in the data array) I get a crash. XCode 6.1.1, iOS 8.

2015-02-09 13:59:39.385 Visibility[51692:2100147] ***Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM objectAtIndex:]: index 13 beyond bounds [0 .. 12]'
*** First throw call stack:
(
	0 CoreFoundation 0x00000001124abf35 __exceptionPreprocess + 165
	1 libobjc.A.dylib 0x0000000112144bb7 objc_exception_throw + 45
	2 CoreFoundation 0x0000000112396f33 -[__NSArrayM objectAtIndex:] + 227
	3 Visibility 0x000000010fccbe71 -[SChartBarColumnSeries drawBin:withDrawer:withGLBaseline:andGLTranslation:currentRenderIndexDict:] + 1649
	4 Visibility 0x000000010fca14b5 -[SChartMappedSeries drawWithCanvas:withGLBaseline:andGLTranslation:] + 1237
	5 Visibility 0x000000010fd3c36d -[SChartMappedSeriesGroup drawSingleSeries:onChart:] + 285
	6 Visibility 0x000000010fd343ed -[SChartCartesianSeriesGroup drawStackedSeries:onChart:] + 125
	7 Visibility 0x000000010fd347cd -[SChartCartesianSeriesGroup drawSeriesOnChart:] + 925
	8 Visibility 0x000000010fd05d33 -[SChartCanvas drawChart:] + 3235
	9 Visibility 0x000000010fd00d9c -[SChartCanvasRenderView drawRect:] + 92
	10 UIKit 0x0000000110a66569 -[UIView(CALayerDelegate) drawLayer:inContext:] + 496
	11 QuartzCore 0x000000011041b942 -[CALayer drawInContext:] + 113
	12 QuartzCore 0x000000011041b35e _ZN2CA5Layer8display_Ev + 562
	13 QuartzCore 0x0000000110410801 _ZN2CA5Layer17display_if_neededEPNS_11TransactionE + 301
	14 QuartzCore 0x0000000110410889 _ZN2CA5Layer28layout_and_display_if_neededEPNS_11TransactionE + 35
	15 QuartzCore 0x000000011037e63e _ZN2CA7Context18commit_transactionEPNS_11TransactionE + 242
	16 QuartzCore 0x000000011037f74a _ZN2CA11Transaction6commitEv + 390
	17 QuartzCore 0x000000011037fdb5 _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv + 89
	18 CoreFoundation 0x00000001123e0dc7 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
	19 CoreFoundation 0x00000001123e0d20 __CFRunLoopDoObservers + 368
	20 CoreFoundation 0x00000001123d6b53 __CFRunLoopRun + 1123
	21 CoreFoundation 0x00000001123d6486 CFRunLoopRunSpecific + 470
	22 GraphicsServices 0x00000001139309f0 GSEventRunModal + 161
	23 UIKit 0x00000001109ed420 UIApplicationMain + 1282
	24 Visibility 0x000000010fc57603 main + 115
	25 libdyld.dylib 0x00000001176d7145 start + 1
	26 ??? 0x0000000000000001 0x0 + 1
)

And the following is the code where I set up the ordering of the data points:

for(int i = 0; i < [_rawVenueData count]; i++) {
        MyCustomClass *currentVenue = [_rawVenueData objectAtIndex:i];
        NSSortDescriptor *sorter = [[NSSortDescriptor alloc] initWithKey:@"salesPercent" ascending:YES];
        NSArray* unsortedArray = [currentVenue.categories copy];
        NSArray* sortDescriptors = @[sorter];
        NSArray *newArray = [unsortedArray sortedArrayUsingDescriptors:sortDescriptors];
        [mutableDisplayData addObject:[NSArray arrayWithArray:newArray]];
    }

“In the meantime, the key point to take away here is that the chart now requires series to contain ordered data if you are stacking series.”

Seems kind of counter-productive, no? Example:

Dataset1: {A:3; B:15; C:14}

Dataset2: {A:6; B:11; C:8}

Dataset3: {A:4; B:9; C:8}

**** Dataset4: {A:6; B:10; C:13};

So, according to the data (if we ignore Dataset 4), the series ordering should be A, C, B as this is ascending order. But if we throw in Dataset4 it does not follow that pattern, and thus would cause an error by this modeling.

The odd thing is; it works for any data I try to put in for any ordering, even the above case, but once the number of datasets exceeds 12, boom crash.

Sample in-app render (labels removed for y-axis values):

 Who’s to say I won’t sell more dessert items than hamburgers today at at least one of my restaurants? Or more Toyotas than Nissans at one of my car dealerships? 

Hopefully this gets the attention it deserves.


#4

bump


#5

Hi,

I’m afraid I can’t reproduce your issue, though this may be me misunderstanding your issue.

Would you mind sending a sample application that replicates the issue to info@shinobicontrols.com? I’ll then try and take a look at it on Monday morning.

Thanks,

Sam