Почему инструменты сообщают об утечке памяти в этом коде? - PullRequest
Новая
       3

Почему инструменты сообщают об утечке памяти в этом коде?

1 голос
/ 20 августа 2010

Быстрый вопрос, Прибор сообщает об утечке здесь ... 

MyViewController *myVC = [[MyViewController alloc] initWithNibName:@"myView" bundle:nil];     
[self.navigationController pushViewController:myVC animated:YES];  //<<<<---- !00% leak according to Instruments
[myVC release];

Я понимаю, что myVC сохраняется контроллером nav, поэтому я предполагаю, что контроллер nav освобождает их, когда представление выталкивается из стека nav?

Кроме того, в одном из моих циклов есть еще один хитрый, статический анализатор сообщает о потенциальной утечке ... 

//Walk through the scheduled alarms and create notifications
NSMutableArray *fireDates = [[NSMutableArray alloc] init];
for(NSDate *fireDate in fireDates)          //<<<<---- Static analyzer is reporting potential leak here
{
     UILocalNotification *localNotif = [[UILocalNotification alloc] init];
    if (localNotif == nil)
    {
        [fireDates release];
        return;
    }

    localNotif.fireDate = fireDate;  
    localNotif.timeZone = [NSTimeZone defaultTimeZone];

    localNotif.alertBody = [NSString stringWithFormat:@"%@", alarm.Label];
    localNotif.alertAction = NSLocalizedString(@"Launch", nil);

    localNotif.soundName = UILocalNotificationDefaultSoundName;

    localNotif.userInfo = infoDict;
    localNotif.repeatInterval = NSWeekCalendarUnit;

    [[UIApplication sharedApplication] scheduleLocalNotification:localNotif];
    [localNotif release];

}
[fireDates release];

Нужно ли как-то выпускать fireDate?

Заранее спасибо за помощь!

Ответы [ 2 ]

1 голос
/ 20 августа 2010

Эти фрагменты хороши, так как фрагменты идут. Не видя вашего полного кода, невозможно сказать, если вы не делаете что-то глупое в другом месте. Вы когда-нибудь выпускали ваш navigationController (в вашем приложении делегат -dealloc, скорее всего)? Это утечка, которая ничего не значит, но это может быть тем, что вызывает первое предупреждение.

Редактировать : что касается второго фрагмента, то код выглядит нормально (хотя в случае возврата с помощью ярлыка некоторые кодеры будут беспокоить, кто предпочитает видеть оператор break). Статический анализатор может быть обеспокоен отсутствием [localNotif release] (хотя это явно не нужно) в условном возврате.

0 голосов
/ 20 августа 2010

В первом фрагменте, что просочилось?Приборы сообщат вам строку, где она была выделена, которая часто не является строкой, «ответственной» за утечку (конечно, номера строк, как правило, отключены, потому что это дает вам адрес возврата, а не адрес вызова).Я предполагаю, что происходит утечка MyViewController, и что инструменты на самом деле жалуются на alloc (посмотрите на backtrace, cmd-E, я думаю).

Если вы нажмете стрелку рядом с адресом памяти (вы можетепридется немного кликнуть и навести курсор на адрес утечки; я не помню) вы увидите все вызовы alloc / retain / release / autorelease / malloc / free / CFRetain / CFRelease по этому адресу.Игнорируйте те, которые находятся перед alloc (они относятся к предыдущему объекту, который, как оказалось, жил по тому же адресу).Матч сохраняет и (авто) выпускает.Вы можете сопоставить автоматическое освобождение с соответствующим (отложенным) выпуском, потому что отложенное высвобождение произойдет, когда NSAutoreleasePool будет освобожден (что очевидно в трассировке стека).Ищите удержание без соответствующего (авто) выпуска.Это утечка.

Во втором случае полезно, если вы скажете нам, что Clang SA говорит вам (нажмите на маленький треугольник слева, и он развернется, чтобы показать вам поток управления, где происходит утечка).

Но я не думаю, что цикл вообще работает, потому что fireDates пусто.

...