libsystem_c.dylib中的內存泄漏

我在我的應用程序中發現了一個內存泄漏，這是一個ARC轉換的應用程序。libsystem_c.dylib中的內存泄漏

儀表顯示，泄漏負責圖書館libsystem_c.dylib

我附上這裏的屏幕截圖..

我已經搜索這件事，我找到了相關的帖子在

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

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

它是iOS 5.1框架中的錯誤嗎？

對此的任何幫助表示讚賞。

enter image description here

來源

2012-08-02 Shamsudheen TK

我將此解釋爲'strdup'函數創建的字符串永遠不會被釋放。如果您不使用'strdup'，則問題可能在其他地方。你可以發佈追蹤的電話？ – Krumelur 2012-08-02 07:02:06

是的，它現在是5.1和5.1.1中已知的一個bug。如果我沒有記錯的話，與scrollviews相關。 – danielbeard 2012-08-02 07:25:42

編輯：

確實，似乎存在的iOS SDK 5.1的strdup（或相關）的bug一些王。看到這個線程從developers forum。

如果您可以在Elements示例（據說可以揭示該bug）中查找並查看您是否使用相同類型的功能，那將會很有趣。

這是在泄漏的時刻堆棧跟蹤：

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

您可以通過在儀器中選擇「顯示擴展詳細信息」（或類似的東西），我們就到泄漏的那一刻你的堆棧跟蹤查看菜單。我不認爲它不是。

實際上，Instrument爲您顯示的「負責任的庫」是實際調用malloc的地方。

如果你看看儀器的輸出，罪魁禍首是strdup：在strdup不可能有泄漏。

這更可能是您要求操作系統（直接或間接）複製某些字符串，但後來又錯誤地管理了字符串的結果副本。

分析儀器爲您提供的擴展詳細視圖，其中顯示調用malloc時調用堆棧。這可能幫助如果您的代碼和malloc調用本身之間有直接關係。但即使詳細視圖不顯示這種關係，請繼續查找代碼中泄漏的原因。更多一般情況下，嘗試瞭解發現泄漏時應用程序的哪個部分正在運行（考慮到在離散時間分析泄漏的事實，例如，，每10秒鐘一次，所以當你看到紅條出現時，這意味着泄漏是在最近10秒內產生的），並檢查你在相關類中做的所有記憶操作。

以我的經驗來看，儀器將SDK的某些部分顯示爲泄漏的「負責任」是非常正常的（100％的情況），但是在更深入的分析中，錯誤的代碼是我的一部分。

來源

2012-08-02 07:00:12 sergio

libsystem_c.dylib中的內存泄漏

回答

相關問題