False Positive (?) in Leaks Instrument

I'm unsure how to interpret a result from the 'Leak Checks' Instrument in 'Pure C' code. At the very beginning of a test run I see a leak reported. If I let the run proceed the test end occurs and the reported leak shows up with an 'Event Type' of 'free' - with a backtrace showing the exact function call sequence where I'd expect the memory to be freed.


Why am I getting a leak reported in the first place?


If this is a common 'false positive' then the only option I see is to check each reported leak to see if it actually got freed later. Let's just say 'tedious'.


https://ibb.co/PTJp9rS


Image shows a single leak, in the selected region. Looking at the history for that memory location shows a 'malloc' and a 'free' - why the leak?

Accepted Reply

There was a bug here, it should have been fixed as of iOS 12.4 beta 4.

Replies

I'd consider the objective c (and probably pure c) part of Instruments 10.2 being broken when running on a real device (iOS 12.2).

First it looked to me as if ARC part would compile the code without releases or as if autorelease pool would not be running at all.


Also all these leaked objects are reported as "malloc 64", not as the objects that are really allocated.


Then I started to mark generations and I saw that there is no growth whatsoever that would be related to these "leaks". Then I selected several of these "leak" marks in the one sweep and I saw exactly what you see, these mallocs got matched by the corresponding Free.


Nothing like this happens to the Swift part (now compiled as Swift 5).


Nothing like this happens when profiling leaks in simulator of iOS 12.2.


I hope this is just some setting/knob I miss and this is not a part of a "we don't care about objective c anymore" thing.


Will be bug reporting to Apple.


If you share what is your Xcode, iOS version is might help to understand when the problem started to happen. I have such a feeling that I've profiled a lot under Xcode 10.1/iOS 12.2 on real devices and neither of this was happening.


Update: Reported to Apple under bug id 49265060

There was a bug here, it should have been fixed as of iOS 12.4 beta 4.