In my app, I have am receiving multiple memory leaks. The object is Malloc 48 bytes, and it always originates from the responsible caller strdup. The history of the object only shows it being Malloced, and no other retains or releases. The stacktrace doesn't show any of my code. The only bits of relevance that I can pick out are:
10 UIKit _UIGestureRecognizerSendActions
9 UIKit -[UIScrollView handlePan:]
8 UIKit -[UIScrollView _endPanWithEvent:]
7 UIKit -[UIScrollView(Static) _startTimer:]
6 CoreFoundation CFNotificationCenterAddObserver
5 CoreFoundation _CFXNotificationRegisterObserver
4 libnotify.dylib notify_register_dispatch
3 libnotify.dylib notify_register_mach_port
2 libnotify.dylib token_table_add
1 libsystem_c.dylib strdup
0 libsystem_c.dylib malloc
It seems to occur whilst scrolling on a map view, but I am unsure how to proceed as none of my code is referenced in the stack. How should I proceed in diagnosing this leak?
If any further information is required, please let me know.
Regards,
Nick
If it is "only" 48 bytes, all evidence points to frames in the system frameworks (i.e. the allocation is never exposed to your code), and there are not 10s of thousands of 'em, then I (a) wouldn't worry about it too much, but I would (b) immediately file a bug via http://bugreport.apple.com/
Attach a binary of your application and instructions as to how to reproduce the issue.
I think I've confirmed it was introduced in 5.1. I am able to duplicate the memory leak every time in my app by pressing the home button when my app is active with a UIScrollView as the active view using iPhone simulator 5.1. The same test running on iPhone simulator 5.0 does not reproduce the error.
Hope this helps
Just to confirm that this is indeed a reoccurring issue and not just you having a problem. I have seen this happen in Table scrolling as well as UIScrollView. I've tested it in simulator, as well as profiling the release versions on an iPad. Seems to be a common problem in 5.1 but I have yet to hear of a fix. And I do agree, 48bytes at every scroll could potentially become an issue.
it might be caused by performselectorinbackground, call it inside of @autoreleasepool{} block
