Instrumente zeigen leak im main.m (Xcode 4.3.1)
Bin ich, eine app zu entwickeln mit der ARC
Beim profiling meine app in Instrumenten, die für Speicherlecks zeigt es Leckagen in der folgenden Funktion:
#import <UIKit/UIKit.h>
#import "AppDelegate.h"
int main(int argc, char *argv[])
{
@autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
Weist das auf ein problem irgendwo in meinem code?
Dies ist die Stapelüberwachung
0 libsystem_c.dylib malloc
1 libsystem_c.dylib strdup
2 libnotify_sim.dylib token_table_add
3 libnotify_sim.dylib notify_register_mach_port
4 libnotify_sim.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 -[UIGestureRecognizer _delayedUpdateGesture]
13 UIKit ___UIGestureRecognizerUpdate_block_invoke_0541
14 UIKit _UIGestureRecognizerApplyBlocksToArray
15 UIKit _UIGestureRecognizerUpdate
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_SOURCE1_PERFORM_FUNCTION__
22 CoreFoundation __CFRunLoopDoSource1
23 CoreFoundation __CFRunLoopRun
24 CoreFoundation CFRunLoopRunSpecific
25 CoreFoundation CFRunLoopRunInMode
26 GraphicsServices GSEventRunModal
27 GraphicsServices GSEventRun
28 UIKit UIApplicationMain
29 MyProject/main.m:16
30 MyProject start
- haben Sie irgendwelche spezifischen Protokolle & error-codes? da Sie nicht schreiben, diese Funktion selbst das problem wil liegen in Ihrem eigenen code =)
- Hat dieser Leck Eintrag in Instrumenten, die helfen? Ich bekomme rund 10 Einträge wie diese für zwei Minuten ausführen meiner app: undichte Objekt: Malloc 48 bytes, Bibliothek Verantwortlich: libsystem_c.dylib Verantwortlich frame: strdup.
- Sie sollten in der Lage sein, um klicken Sie auf die Adresse von diesem malloc-block & Holen Sie sich einen stack-trace von dort, die Ihnen helfen sollen herauszufinden, wo es herkommt. aber sehr ehrlich zu sein - 10x-48 bytes-Leck ist nicht das Ende Welt, wenn es bleibt an diesem 😉
- Vielen Dank für Ihre Antwort. Ich aktualisiert meine Frage mit dem stack-trace, in Fall, dass Sie wollen, um einen Blick zu haben. Ich bin nicht erfahren genug, um zu verstehen, wo das Leck liegt in der stack-trace
- ich bin aus meinem domain jetzt auch - aber ich denke, dass mit diesen zusätzlichen Informationen könnte jemand anderes in der Lage sein, um Ihnen zu helfen 🙂
- Long shot, aber vielleicht haben Sie verpasst ein
[super dealloc]
irgendwo in deinem code wenn du hast Unterklassen eines view-controller? - [super dealloc] ist nicht zulässig, wenn mit ARC
Du musst angemeldet sein, um einen Kommentar abzugeben.
Scheint es ein bug in der iOS 5.1 Rahmen:
https://devforums.apple.com/message/630695
Ich hatte das gleiche problem während der Verwendung von ARC und es wurde dadurch verursacht, dass die dealloc-Funktion in eine view-controller. Durch die dealloc-Funktion (das hat nicht alles, was in meinem Fall), die default-Verhalten kann nicht aufgerufen werden. Versuchen Sie, kommentieren Sie alle Instanzen von dealloc und dass sollte dein problem lösen.
Ihrem Haupt.m sieht anders aus als andere, die ich gesehen habe. Hast du das format es so oder war es geschehen, dass der Weg automatisch? Hier ist ein Beispiel aus einem meiner ARC apps.