18

In my app I have a scroll view and four table views. Each time one is dragged and then released, I get a 48 byte leak. This really adds up. As you can see, both groups of leaks have the same source. Has anyone seen a leak like this before?

Edit 1:

When I click on the arrow next to the leak, I get this information for the leak:

eric.mitchell
  • 8,817
  • 12
  • 54
  • 92

4 Answers4

28

What you are seeing is a known bug in iOS 5.1 and is being discussed in the iOS Developer Forums as such. You can find the relevant thread by searching in the forums for "strdup". See the thread titled "Elements App Memory Leak". Search for the post from an Apple employee.

Cliff Ribaudo
  • 8,932
  • 2
  • 55
  • 78
0

A workaround:

I realised that somehow this leaked bytes are stored within the scrollview. You have to release your scrollview and alloc it again from time to time, keeping its state. The way you detect when you should reload the scrollview is up to you, depends on your app needs. Every time you release the scrollview, these bytes are also released.

Roger Sanoli
  • 753
  • 10
  • 10
  • No, I got scroll views and table views that are alloc and dealloc'd from time to time, and that does not fix the leak. The solution is simply to wait for the official fix in ios. – 勿绮语 Apr 21 '12 at 03:11
0

Workaround: I found that the memory leak occurred in handlePan: if the UIScrollView delegate is set. I needed the delegate methods, so I subclassed UIScrollView, and declared my own @protocol. Then I overrode the target selector for the scrollView panGestureRecognizer, without sending it to super:

//yourScrollView.h
@protocol yourScrollViewDelegate
-(void)yourProtocol;
@end

//yourScrollView.m
-(void)handlePan:(id)sender{
   [yourDelegate yourProtocol];
}
Jesse Gumpo
  • 4,777
  • 1
  • 20
  • 29
0

Most likely, it's your fault, somehow.

In the Allocations instrument, press the "i" button and turn on "Record Reference Counts". Then Instruments can show you all the allocation, retain, autorelease, and release events that happened to those objects. (You should see an arrow next to each leaked item -- click it to show the allocation history of that object.)

I think you'll find that some of your code is retaining something, or indirectly causing it to be retained. Probably the scroll view or one of its gesture recognizers, as a guess.

Kurt Revis
  • 27,695
  • 5
  • 68
  • 74
  • Record Reference Counts is turned on, but how do I see the leaked objects from within Allocations? I can see the leaked objects in Leaks (duh), but I can't see where they were retained/released/autoreleased. – eric.mitchell Mar 19 '12 at 14:41
  • I just tried this using Xcode 4.3.1, using the "Leaks" preset in Instruments. Record Reference Counts was already turned on. In the list of leaked objects, in the "Address" column, there is an arrow icon -- click that to show the history of that address. If the arrow isn't showing up, best I can suggest is to play with the settings in Instruments. – Kurt Revis Mar 19 '12 at 17:35
  • Found it, but the information there isn't extremely helpful. Editing in my results. – eric.mitchell Mar 19 '12 at 17:58
  • Hmph. Well, then, time to guess. The backtrace looks like the `UIScrollView` is starting a timer and/or registering for a notification, when the pan gesture ends. Are you doing anything when a scroll ends? Do you subclass the scroll view and override methods in it, or install your own gesture recognizers? If you're overriding any methods in views or view controllers, are you sure you're calling `super` when appropriate? – Kurt Revis Mar 19 '12 at 18:24
  • I'm not overriding or subclassing anything. – eric.mitchell Apr 01 '12 at 02:03
  • 1
    Actually not his fault. I was able to repeat this exact leak with a bare minimum app. Every time you scroll it, it leaks 48 bytes in libsystem_c.dylib. Same happens with both table view and scroll view. – 勿绮语 Apr 21 '12 at 03:16
  • 1
    Yes, I agree, at this point it's clearly Apple's bug. This was the first report I had seen of it, and usually it's rare to find such an obvious leak in the frameworks. – Kurt Revis Apr 21 '12 at 04:16