Memory Leak in libsystem_c.dylib

Question

I have found a memory leak in my application which is a ARC converted application.

Instrument shows that leak responsible library is libsystem_c.dylib

I am attaching the screen shot here..

I have searched about the issue and i found the related posts in

instruments-show-leak-in-main-m-xcode-4-3-1

obj-c-memory-leak-of-malloc-48-bytes-in-strdup-framework

Is it a bug in the iOS 5.1 framework?

Any help on this is appreciated.

enter image description here

I interpret this as a string created by the strdup function never gets freed. If you don't use strdup the problem could be elsewhere. Could you post a traceback of the calls? — Krumelur
Yes it is a known bug in 5.1 and 5.1.1 at the moment. Related to scrollviews if I remember correctly. — danielbeard

sergio sergio · Accepted Answer · 2012-08-02T07:00:12

EDIT:

indeed, it seems there is some king of bug in iOS SDK 5.1 strdup (or related). See this thread from the developers forum.

it would be interesting if you can dig a bit into the Elements sample (which is the one that is said to reveal the bug) and see if you are using the same kind of functionality.

Here is a stack trace at the moment of the leak:

 0 libsystem_c.dylib malloc
 1 libsystem_c.dylib strdup
 2 libnotify.dylib token_table_add
 3 libnotify.dylib notify_register_mach_port
 4 libnotify.dylib notify_register_dispatch
 5 CoreFoundation _CFXNotificationRegisterObserver
 6 CoreFoundation CFNotificationCenterAddObserver
 7 UIKit -[UIScrollView(Static) _startTimer:]
 8 UIKit -[UIScrollView _endPanWithEvent:]
 9 UIKit -[UIScrollView handlePan:]
10 UIKit _UIGestureRecognizerSendActions
11 UIKit -[UIGestureRecognizer _updateGestureWithEvent:]
12 UIKit ___UIGestureRecognizerUpdate_block_invoke_0541
13 UIKit _UIGestureRecognizerApplyBlocksToArray
14 UIKit _UIGestureRecognizerUpdate
15 UIKit _UIGestureRecognizerUpdateGesturesFromSendEvent
16 UIKit -[UIWindow _sendGesturesForEvent:]
17 UIKit -[UIWindow sendEvent:]
18 UIKit -[UIApplication sendEvent:]
19 UIKit _UIApplicationHandleEvent
20 GraphicsServices PurpleEventCallback
21 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
22 CoreFoundation __CFRunLoopDoSources0
23 CoreFoundation __CFRunLoopRun
24 CoreFoundation CFRunLoopRunSpecific
25 CoreFoundation CFRunLoopRunInMode
26 GraphicsServices GSEventRunModal
27 UIKit UIApplicationMain
28 TheElements 0x300a
29 TheElements 0x2fc3

You can get your stack trace at the moment of the leak by choosing "Show Extended Detail" (or something similar) in the Instruments View menu.

OLD ANSWER:

I suspect it is not.

In fact, what Instruments shows you as "responsible library" is the place where the actual malloc call was effectively executed.

If you look at Instruments output, the culprit call is strdup: there cannot possibly be a leak in strdup.

It is more likely that you asked the OS (directly or indirectly) to duplicate some string, but then managed incorrectly the resulting copy of the string.

Analyze the Extended Detail View which Instruments offer you, which shows the call stack at the moment the malloc was called. This may help if there is a direct relationship between your code and the malloc call itself. But even if the detailed view does not show such relationship, keep looking for the cause of the leak in your code.

More in general, try to understand which part of your app is running when the leak is found (take into account the fact that leaks analysed at discrete times, e.g., every 10 seconds, so when you see the red bar appear, that means that the leak was produced during the last 10 seconds), and review all memory operations you do in the relevant classes.

In my experience, it is pretty normal (100% of cases) that Instruments shows some part of the SDK as "responsible" for a leak, but at a deeper analysis the wrong code is on my part.

Memory Leak in libsystem_c.dylib

1 Answers