App crash by a bug in piecharts SChartSpokesView - explanation and workaround


Used ShinobiCharts in version:

We observed a crash in our “Ready for Sale” app that was caused by a piechart.
The stacktrace indicated that it happened inside -[SChartSpokesView drawRect:].

Luckily, we were able to reproduce the crash after a long analyzing night!

It became apparent, that when after a -[ShinobiChart reloadData] a redraw of the ShinobiChart is forced, a new SChartSpokesView gets created and added as a subview to the chart, whereas the previously created SChartSpokesView is not removed from the view-hierarchy.

This may happen due to

  • a following call on redrawChart
  • or redrawChartIncludePlotArea:
  • or, which is the worst, when a layoutSubviews is triggered from anywhere within the app

It occurs under iOS 9.3 and iOS 10 and we could reproduce it with the Xcode 8 simulator, iPad 4, air, air 2 and pro 12.9”.

One of the properties of the leftover SChartSpokesView points to an object that already got released (a Zombie).
Whenever drawRect: is called on that SChartSpokesView, it tries to call a method on the Zombie and - depending on the content of the memory at the address - the app will crash.

It only happens when reloadData and the redraw happens immediately consecutive.

Our workaround is that we no longer call reloadData. Instead we remove the whole chart from the view-hierarchy (removeFromSuperview and setting it to nil), rebuild it from scratch and add it to the view-hierarchy again (addSubview).

This is drastic, unsatisfying, frustrating, lowers the UI performance and influences the user experience negatively.

It may not be applicable to every app, but we can’t risk a crash just because of a simple piechart.

Please find under the attached public Dropbox link a sample-project, in which you can reproduce the behaviour (you have to link it to the ShinobiCharts-framework in order to build and run).
Whenever you hit the “Force redraw”-button in it, it will create a new SChartSpokesView, as you can observe it in the “Debug View Hierarchy”-mode in Xcode.
Setting the SChartSpokesView to ‘hidden’ (which is easier by a tool like Reveal) may crash the app sooner or later.

We hope that this may help other developers using ShinobiCharts and that this bug will be resolved by Shinobi soon.

Thank you,



Hi Klaus,

Thanks for bringing this to our attention & for the detailed bug report!

It’s greatly appreciated!

After some investigation we have found the cause of the issue and it has been fixed and we are aiming to get it included in our next version which will be released shortly.

We will update this forum post when the version containing the fix for this issue has been released.

Let me know if you have any questions.

Kind regards,
Andrew Polkinghorn.


Good afternoon Andrew,

We are also suffering from this crash using

We have a view controller in our application that displays a SChartDonutSeries which represents money spent based on a given category. It is a very basic chart, with all user interaction disabled.

When the underlying spending data changes we call reloadData on the donut chart so that it updates. Unfortunately, this causes the application to crash with the following call:

-[SChartSpokesView drawRect:] - EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x5612ea9a1c1c8e94

In your reply above, you noted that the bug has been fixed but we do not see anything in the release notes since v2.9.0-6. Can you tell me where we can go to get the fix for this crash. Our only option at this point is to either avoid using the donut chart or the work around suggested above.

Warmest regards,



Hi Fredrick,

I’m sorry to hear you are still experiencing the spokes view crash.

I’m unable to reproduce a crash with our spokes view after calling reloadData.

Could you manipulate our “PieChart” sample, to replicate your crash and host it somewhere we can download it or e-mail it to us at The “PieChart” sample can be found in the Samples folder in your Shinobi download.

Let me know if you have any questions.

Kind regards,
Andrew Polkinghorn.