Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First:</p> <p>you have a possible and visible leak, but I'm not sure if it is the same leak you have found in instruments:</p> <p>These two lines are in your viewDidLoad method</p> <pre><code>_carouselItems = [[NSMutableArray alloc] initWithCapacity:1]; _categorymAr = [[NSMutableArray alloc] initWithCapacity:1]; </code></pre> <p>But: <code>viewDidLoad:</code> is called every time the view is loaded by it's controller. If the controller purges the view (for example after a memory warning), at the second viewDidLoad your <code>_carouselItems</code> and <code>_categorymAr</code> instance variables will lost the reference to the previously created NSMutableArray, causing a leak</p> <p>So, change that lines and use the syntesized setters:</p> <pre><code>self.carouselItems = [[[NSMutableArray alloc] initWithCapacity:1] autorelease]; self.categorymAr = [[[NSMutableArray alloc] initWithCapacity:1] autorelease]; </code></pre> <p>the syntesized setter is configured to release the previous object before assignin a new one.</p> <p>However: it's possible that you have another leak. If you can reproduce the leak simply (if I understand, the leak appears simply moving from a VC to another), you can use the "heapshot" function of instruments.</p> <p>Assuming that your leak appears moving from the first VC to the second and coming back:</p> <ul> <li>open instruments with the allocations tool</li> <li>go from the first VC to the second and come back.</li> <li>press "mark heap" on the left. A line will appear.</li> <li>go again from the first VC to the second and come back.</li> <li>press "heapshot" again</li> <li>do this several times (9-10)</li> </ul> <p>the heapshot tool takes a "snapshot" of the living objects at the time you pushed the button and shows you only the difference. If there are 2-3 new objects, you will see it in the list.</p> <p>This is a good starting point to investigate a leak. Look at the attached image:</p> <p><img src="https://i.stack.imgur.com/vRKsk.png" alt="Heapshot analysis"></p> <p>Consider that you must mark the heap several time and discriminate "false positive" by looking at the object created, in my example you can se a possible leak (heapshot5, 1,66KB), but after looking at the content it's not --> it was a background task that started in that moment.</p> <p>Moreover, delays of the autorelease pool and the cache of some UIKit objects can show something in the heapshot, this is why I say to try it several times.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload