Home/ Questions/Q 5965865
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-22T19:42:03+00:00

do the entries in the XCode profiler Leaked Blocks table imply there was definite

  • 0

do the entries in the XCode profiler “Leaked Blocks” table imply there was definite leakage?

That is assuming I run my iPhone app under profiler, than look at the leaked blocks information. so there are multiple NSDate rows at the top of my list. If I click on one of these rows I can navigate down to the bit of code in question.

So I’m wanting to confirm do all instances of entries in the “Leaked Blocks” table imply there is a real leakage there, that requires coding to be updated/fixed to resolve?

NOTE – One of the reasons I ask is that the code I posted here do I have to release the NSDate in this code below? for example was from code that the profiler highed to me under “Leaked Blocks”, however the code (refer to this post) was reviewed by others and they tell me it’s fine.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    do the entries in the XCode profiler “Leaked Blocks” table imply there was definite leakage?

    yes.

    leaks are evaluated in a lazy manner. leaks is not guaranteed to catch all leaks because it does not actually record all references – it just scans the process’s memory (including stacks and registers) for patterns (e.g. the pointer value) of active allocations.

    man leaks will give you specifics of the implementation, and the WEAKNESSES section confirms my response to your question, and gives an example of a circumstance where leaks will not be detected.

    if you manage your allocations in a truly convoluted way (e.g. pointer arithmetic/offsets), you could in fact work around the system and introduce false positives — don’t do that =)

    when you post code at SO and people tell you it’s right, they mean the program you posted is correct – the leak (reference count imbalance in this case) is introduced in another part of your program. that is, the pointer you return (newDate in the link) is not correctly ref-counted by the caller, or who the caller passes it to.

    instruments all record all ref counts for you – in case static analysis returns no issues.

    specifically, instruments is showing you where the leaked allocation/object was created.

    hope that helps.

    • 0