Понимание утилиты командной строки 'утечек' для нахождения утечек памяти
Я не уверен, что вам это нужно, но вот решение из того, что я узнал:
timestamp = "00:00:16,260".split(":")
seconds= float(timestamp[2].replace(',', "."))
minutes = int(timestamp[1])
hours = int(timestamp[0])
milliseconds= seconds*1000 + minutes*60*1000 + hours*3600*1000
3 ответа
В выводе, который вы показали, нет трассировки стека. Адреса, которые вы видите, являются собственными адресами объектов, а не указателями на функции, а шестнадцатеричные числа рядом с символами пунктуации являются просто шестнадцатеричным дампом данных.
Чтобы узнать, где был размещен объект из , установите MallocStackLogging в среде утечки:
% MallocStackLogging=1 leaks …
Вы также можете использовать опцию -nocontent, которая будет подавлять шестнадцатеричный дамп. Однако не используйте это все время: иногда шестнадцатеричный дамп содержит ценную подсказку.
Кроме того, утечки не обязательно говорят вам, что у вас есть три утечки; точнее говоря, это говорит о том, что у вас есть три утечки объекта . Преднамеренная утечка, которую вы показали, производит только один протекший объект, но другая утечка (например, в цикле или часто называемом методе) может привести к утечке многих объектов.
Редактировать: Кстати, некоторые из этих утечек происходят из SIMBL или одного или нескольких ваших плагинов SIMBL. Отключите SIMBL и любые другие хаки менеджера ввода перед поиском утечки. Помните, что код работает в вашем процессе; более того, утечкам не важно, чей код выделил или утечка памяти, а только то, что она просочилась, поэтому он покажет просочившийся объект независимо от того, кто его выделил или утек.
Для этого примера, утечки сообщают о 3 утечках в общей сложности 128 байтов. Интерпретация должна быть следующей:
1) у вас есть утечка NSMutableString, которая, по-видимому, реализована внутренне как NSCFDictionary на общую сумму 64 байта
2) вы сдает Тестирование 1 на общую сумму 32 байта
3) вы пропускаете \ nTesting 2 в общей сложности для 32 байтов
Это должно быть потому, что если вы не освободите NSMutableString, ни один из объектов (в данном случае строк), принадлежащих структуре данных NSCFDictionary, не будет освобожден: они сохраняются каждый раз, когда вы используете метод appendString. Когда вы освобождаете NSMutableString, все объекты внутри NSCFDictionary автоматически освобождаются вместе с самим NSCFDictionary.
Из документации Apple ( http://developer.apple. ru / iPhone / библиотека / документация / производительность / концептуальная / ManagingMemory / Articles / FindingLeaks.html ):
Если объект Какао автоматически освобожден без установленного пула автоматического выпуска, Xcode отправляет сообщение на консоль, предупреждая вас что объект просто протекает. Даже если вы не пишете приложение Какао, вы можете увидеть такой же тип предупреждения консоли. Реализация многих классов Какао основана на базовых типах. Если ваше приложение использует Core Foundation, возможно, что утечки происходят в результате обращений к этой платформе.
Чтобы найти утечки памяти этого типа, используйте отладчик, чтобы установить точку останова в функции _NSAutoreleaseNoPool. Эта функция объявлена в NSDebug.h в рамках Основы. Когда отладчик достигает этой функции,
I think the reason you are seeing this in leaks is because appendString is using autorelease internally. The autorelease pool isn't being discarded until the next 'event'. Basically, I think the sample is too simple to accurately show what's going on.
I could be way off base here, but I would try wrapping your code in an autorelease pool to see what changes.
-(void)applicationDidFinishLaunching:(NSNotification *)notification;
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSMutableString *test = [[NSMutableString alloc] init];
[test appendString:@"Testing 1"];
[test appendString:@"\nTesting 2"];
NSLog(@"%@", test);
[test release], test = nil;
[pool release] // this should drain the autorelease pool
}