Премини към съдържанието
Ремонт на покриви | Ремонт на покриви цени | Хидроизолация на покриви

  • 0

managedObjectContext leak-ва


iHustle

Въпрос

Забелязах нещо интересно (поне за мен) и не можах да намеря обяснения на проблема из нет-а.

Ползвам CoreData и когато извикам примерно

NSArray *arr = [moc executeFetchRequest:request error:&error];

в Leaks tool-а казва, че при това положение има leak. Когато същевременно правя и heapshot-и показва същото.

Пробвах друг вариант - декларирах arr като глобален array и го ползвам така:

arr = [[moc executeFetchRequest:request error:&error] retain];

Ако не използвам reatin, приложението гърми. После в dealloc си викам [arr release];

В този случай пак показва, че има leak-ове, но при heapshot-ите всичко се норамлизира и след 2-3 опита Heap Growth става на 0 bytes, а # Still live - 0.

Загубите не са големи - 80bytes, но все пак ми е интересно да знам има ли вариант въобще да няма проблеми(защото все пак managedObjectContext-a(moc както съм го писал аз) си е apple-ски клас и не ми се струва нормално там да има пропуски) и дали като цяло втория вариант с глобалния масив е по-добър от първия?

Линк към коментара
Сподели в други сайтове

6 отговора на този въпрос

Recommended Posts

  • 0

А замислял ли си се дали няма грешки в самите Apple и да си прахосал няколко дена да ги издирваш?

Лично за мен първия вариант е по-добър. Все пак автоматичното освобождаване е благинка.

Втория вариант е алтернативен и не е по-зле от първия, но трябва да НЕ забравяш да освободиш arr когато приключи. При един обект е лесно, но когато станат доста и се намесят външни фактори става трудно.

На кой iOS го пробваш или на Симулатор? Пробвай да мръднеш версиите нагоре/надолу.

Линк към коментара
Сподели в други сайтове

  • 0

@iHustle - От това, което си написал е малко трудно да се ориетира човек какво точно се случва. При всички положения вероятността да има leak вътре в самата CoreData както предполага bgdn е почти нулев. Работата с инструментите за откриване на leak-ове е малко трудна и е лесно да се подведеш, че има leak а то всъщност да няма. Конретно за сорса, който си посочил мога да ти кажа следното:

Метода executeFetchRequest връща autorelease обект, който можеш да го ползваш само в рамките на същата функция освен ако не го retain-неш (NSAutoReleasePool-а ще го освободи след излизане от фукцията). Ето пример:


@interface DummyClass: NSObject {
NSArray *arr;
....
}

-(void) loadData;
......
@end


@implementation DummyClass
....
-(void) loadData {
NSError *error;

// Обекта arr ще се освободи след приключването на метода loadData . Тази конструкция е
// допустима ако ползваш arr обекта само в рамките на loadData метода (съответно няма нужда да е member на класа)
arr = [moc executeFetchRequest:request error:&error];
....
// Ако искаш да ползваш arr обекта и в други методи трябва да го retain-неш и
// съответно да го release-неш в dealloc метода
arr = [[moc executeFetchRequest:request error:&error] retain];
....
}

-(void) dealloc {
// Тук трябва да освобождиш arr обекта само ако си го retain-нал
// в loadData метода - иначе ще гръмне.
[arr release];
....
[super dealloc];
}

......
@end

Линк към коментара
Сподели в други сайтове

  • 0

@iHustle - напиши някакъв "HelloWorld" пример да го видим и ние. Без код наистина не може да се види къде е проблема.

@intruder - явно в Apple работят не-човеци защото изключваш проблеми в тяхната имплементация. :naughty3:

Линк към коментара
Сподели в други сайтове

  • 0

На симулатора тествам. Иначе абсолютно същия пример е и при мен и при двата случая има leak! Изглежда проблема е в телевизора на Apple обаче. Което според мен е тъпо :) Нооо никой не е перфектен. Мерси за отговорите :excl:

Линк към коментара
Сподели в други сайтове

  • 0

@bgdn - Принципно не изключвам проблеми в имплементациите на Apple и затова казах, че вероятността клони към нула - иначе щях да кажа, че няма такава вероятност. В конкретния случай си мисля, че проблема не е в тях, защото вече 4 години откакто се занимавам с Objective-C до сега съм чул само за един документиран случай за leak в SDK-то и то преди години (мисля че беше в MPMoviePlayerController класа). Още повече CoreData framework-а се ползва толкова много, че ако има подобна грешка в него ще я открият и оправят много бързо. ;)

@iHustle - Пак ти казвам - използването не интрументите за откриване на leak-ове никак не е проста работа. Аз и досега не съм открил добро ръководство, в което да е обяснено всички добре.

Редактирано от intruder
Линк към коментара
Сподели в други сайтове

  • 0

Ами това което правя аз е - Run -> Run with performance tool -> Leaks -> разцъквам насам-натам и се появяват едни червени чертички на лентата Leaks. После в листа с leak-ове разглеждам различните такива, като на всеки може да се види през кои методи минава и като избера метод ми показва точно в коя част на кода е предизвикан течът :) Но може и да я има възможността самия tool да засича грешно.

Цялото това обяснение съм го гледал в някакви видеота от WWDC2010.

Линк към коментара
Сподели в други сайтове

Присъединете се към разговора

Можете да публикувате сега и да се регистрирате по-късно. Ако имате акаунт, влезте сега да публикувате с вашия акаунт.

Гост
Отговори на този въпрос...

×   Вмъкнахте текст, който съдържа форматиране.   Премахни форматирането на текста

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Разглеждащи в момента   0 потребители

    • Няма регистрирани потребители разглеждащи тази страница.
Ремонт на покриви | Ремонт на покриви цени | Хидроизолация на покриви

×
×
  • Добави ново...