Memory Leak


#1

I’m using the bar chart sample. In the ShinobiChart+BarChart.m file I add the lines of code below and get major memory leaks when I run the app thru the “leaks” instrument. Any idea why?

        xAxis.enableGesturePanning = true;

    xAxis.enableGestureZooming = true;

    xAxis.enableMomentumPanning = true;

    xAxis.enableMomentumZooming = true;

    xAxis.allowPanningOutOfMaxRange=false;

    xAxis.allowPanningOutOfDefaultRange=false;

    yAxis.enableGesturePanning = true;

    yAxis.enableGestureZooming = true;

    yAxis.enableMomentumPanning = true;

    yAxis.enableMomentumZooming = true;

    yAxis.allowPanningOutOfMaxRange=false;

    yAxis.allowPanningOutOfDefaultRange=false;


#2

Hi Ryan,

Could you let me know a little bit more about the leaks you are seeing please? I tried to reproduce this with the bar chart sample and couldn’t see any major leaks. I saw some really tiny leaks from NSCFNumber and some other tiny leaks in the SChartRange (which we will definitely be investigating now and will fix in the next release), but nothing major. The biggest leak I ever managed to get was 288 Bytes. Here are my results:

If you can share your results and maybe even send us some code or attach a sample project we will happily look into this for you.

Regards,
Chris


#3

Those results are exactly what I get. 288 bytes is not an insignificant amount. Especially when the app has multiple charts that each leak 288 bytes every time you reload them (push and pop nav controllers)

Any time frame when this will be fixed? I’m in need of a charting solution within the next couple of weeks but obviously cannot pay for something tha’ll cause my app to crash eventually


#4

Hi Ryan,

I personally don’t think that 288 bytes is going to cause you any problems. If each chart leaked 288 bytes, you’d need approximately 3600 charts before leaking 1024 Kilobytes / 1 Megabyte, which seems like an awful lot. 

However, saying that, we do recognise that there is a problem here and we have raised this as a critical issue with our charts, meaning that if there does indeed appear to be a problem, we will fix it in our next release. We can’t guarantee that it is a problem at the moment without further investigation (it could be something being reported incorrectly in instruments due to UIColor or NSNumber’s internal caching - we have seen that previously), but we will certainly fix it over the coming weeks in preparation for our next release if it is.

Hope this is helpful for you - if you have any more questions please let us know!

Regards,
Chris


#5

Point proven I was overestimating 288 bytes, its negligible. Still would be nice to see a fix though

Thx Chris!


#6

Hi Ryan,

We agree with you. It’s been raised as a critical issue with our charts even though the leak is small, so we do expect to fix it if it does turn out to be a problem with our code.

Regards,
Chris


#7

I’d like to add that I too see a leak of approx. 352 bytes each time a ShinobiGrid is alloc/init, mostly within your commonInit method (see attached screenshot). Should this too be considered within the normal acceptable range for the product? 


#8

Hi Darren,

The first memory leak that’s displayed in your screenshot is not actually a leak. We’ve looked into this one before and found that it’s a problem with UIKit where instruments misanalyses the the memory from UIColor. This is a known issue with UIKit and doesn’t have anything to do with the memory in our grids.

We haven’t seen anything like your other memory leaks though. Are you using ARC for this project? Could you tell us a bit more about the lifecycle of your grid? If you can send a sample project to info@shinobicontrols.com we will happily take a look at this for you to check that it isn’t a problem with our grids!

Regards,
Chris