CandleStickView Memory leak

[lilidan]

I'm just using the demo. Is it caused by the swift-Objc bridging? Thanks for replying

[liuxuan30]

@danielgindi any ideas? I used to see it once, and I'm gussing it's swift bug or something else, no clue.

[danielgindi]

Did you check for leaks after closing the viewcontroller, or while viewing the charts?..

[lilidan]

If the ChartDataEntry is created in Swift,the leaks won't appear.
It might be a bug of NSArray in swift-Objectivec bridging.

[lilidan]

Finally ,I solved this by changing ChartDataSet.swift

    public init(yVals: [ChartDataEntry]?, label: String?)
    {
        super.init(label: label)

        _yVals = yVals == nil ? [ChartDataEntry]() : yVals

        self.calcMinMax(start: _lastStart, end: _lastEnd)
    }

to

    public init(yVals: [ChartDataEntry]?, label: String?)
    {
        super.init(label: label)

        if yVals == nil {
            _yVals = [ChartDataEntry]()
        }else{
            let yVals_forbug: [ChartDataEntry] = yVals!
            _yVals = yVals_forbug.map({$0})
        }

        self.calcMinMax(start: _lastStart, end: _lastEnd)
    }

It's not elegant,but it works.

[danielgindi]

Wow that's a nasty bug. We need to report this to Apple

[liuxuan30]

I will raise issue today while I am in debugging lab of WWDC. Stay tuned

[liuxuan30]

well I have asked, we investigated into the object, and we found there is a free() eventually, so looks like not a leak, but a leak detector issue...

[liuxuan30]

I asked a debugging expert today, he confirmed that's should be a swift bug, he said the data set pointer to the array is not looks like a pointer, but the object is there, so it report leaks. I filed a bug for this.

Jesus I saw dark magic today.

Xuans-MacBook-Pro:~ xuan$ leaks ChartsDemo
Invalid connection: com.apple.coresymbolicationd
Process:         ChartsDemo [2950]
Path:            /Users/xuan/Library/Developer/CoreSimulator/Devices/F0F16486-FEF7-45F1-8D06-6AE795A47EA5/data/Containers/Bundle/Application/7FDD0D69-1F66-4252-8A61-5E75998947DE/ChartsDemo.app/ChartsDemo
Load Address:    0x10b998000
Identifier:      ChartsDemo
Version:         ???
Code Type:       X86-64
Parent Process:  launchd_sim [2596]

Date/Time:       (null)
Launch Time:     (null)
OS Version:      Mac OS X 10.11.5 (15F34)
Report Version:  7
Analysis Tool:   /Users/xuan/Downloads/Xcode-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/bin/leaks
Analysis Tool Version:  iOS Simulator 10.0 (14A5261u)
----

leaks Report Version:  2.0
Process 2950: 47290 nodes malloced for 67478 KB
Process 2950: 0 leaks for 0 total leaked bytes. <---- watch out

[GeroHerkenrath]

Hello,

I know this is a closed issue, but I was hoping one of you could confirm that I have the same issue and can safely ignore the reported leaks for now. For example, in my project I do

NSArray *yVals = @[[[BarChartDataEntry alloc] initWithValue:(double)[self.dashboardData periodVeryPoorCount] xIndex:0],
                       [[BarChartDataEntry alloc] initWithValue:(double)[self.dashboardData periodPoorCount] xIndex:1],
                       [[BarChartDataEntry alloc] initWithValue:(double)[self.dashboardData periodFairCount] xIndex:2],
                       [[BarChartDataEntry alloc] initWithValue:(double)[self.dashboardData periodGoodCount] xIndex:3],
                       [[BarChartDataEntry alloc] initWithValue:(double)[self.dashboardData periodExcellentCount] xIndex:4]
                       ];

PieChartDataSet *dataSet = [[PieChartDataSet alloc] initWithYVals:yVals];

Instruments reports me leaks here and I could pinpoint it to the same init method as @lilidan. With which I couldn't see anything wrong, so after being confused I landed here...
@liuxuan30, if I understood you correctly, this is just a detection problem related to the bridging to Objective-C?

Sorry, but I'm a little paranoid in this regard, since I'm not that experienced with Instruments (usually it allowed me to easily see the mess I made myself and I was done with it, never had to rely on it extensively...).