Estoy desarrollando una aplicación utilizando ARC Al perfilar mi aplicación en instrumentos de pérdidas de memoria que muestra si hay fugas en la siguiente función:Instrumentos muestran fuga en main.m (Xcode 4.3.1)
#import <UIKit/UIKit.h>
#import "AppDelegate.h"
int main(int argc, char *argv[])
{
@autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
hace esto indicar un problema en otro lugar en mi código?
Este es el seguimiento de la pila
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
¿tiene algún registro específico o código de error? ya que usted no escribió esta función usted mismo, el problema estará en su propio código =) –
¿Ayuda esta entrada de fugas en los instrumentos? Obtengo alrededor de 10 entradas como esta para una ejecución de dos minutos de mi aplicación: Objeto filtrado: Malloc 48 bytes, Biblioteca responsable: libsystem_c.dylib Marco responsable: strdup. –
debería poder hacer clic en la dirección de este bloque malloc y obtener un seguimiento de la pila desde allí que debería ayudarlo a descubrir de dónde viene. pero para ser honesto: 10x 48 bytes de pérdida no son los extremos del mundo si se mantiene así;) –