Превеждане на проследяване на стека на iOS - SIGSEGV/SEGV_ACCERR на viewDidUnload

Предполагам, че този проблем е проблем на жизнения цикъл. Приложението получава предупреждение за паметта и се опитва да разреди някои елементи от потребителския интерфейс. Но не съм 100% сигурен как да тълкувам грешката в контекста на последния отчетен елемент в проследяването на стека.

Exception Type:  SIGSEGV
Exception Codes: SEGV_ACCERR at 0xa0d9f968
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib                     0x361dc026 objc_msgSend_stret + 18
1   TheApp                              0x000b4d31 -**[TheAppFeedController removeAdView]** (TheAppFeedController.m:**189**)
2   TheApp                              0x0000d68d -[TheAppViewController viewDidUnload] (TheAppViewController.m:177)
3   TheApp                              0x000b4a63 -[TheAppFeedController viewDidUnload] (TheAppFeedController.m:137)
4   UIKit                               0x32e66a37 -[UIViewController unloadViewForced:] + 251
5   UIKit                               0x32fae3ad -[UIViewController purgeMemoryForReason:] + 65

Така че проследяването на стека сочи към този метод, който всъщност няма смисъл защо би извел тази грешка.

-(void) removeAdView {
    [super removeAdView];
    [self fixLayoutForAdRemoval:self.tableView];
}

Единственото нещо, което забелязах, когато потърсите стека, е, че [super viewDidUnload] се извиква като първи ред код. Така че го преместих на дъното, след като свърша цялата си работа по "разтоварване". Изглежда има известно несъгласие онлайн дали това наистина има значение или не, някои SO отговори казват, че методът viewDidUnload на супер класа прави нищо и като такова няма значение дали го наричате в началото или в края.

Така че направих тази промяна, но тъй като никога не съм успявал да възпроизведа тази грешка, не съм сигурен дали това е истинската корекция. Исках да получа повече мнения по проблема, за да видя дали разсъжденията ми са правилни.


ios objective-c segmentation-fault
person Joel Martinez    schedule 24.10.2012    source източник
comment
Не съм сигурен, че разбрах: с преместването на [super viewDidUnload], сривът беше коригиран; Ако го възстановите като първи ред, се случва сривът; това ли казваш   -  person sergio    schedule 24.10.2012
comment
Споменах, че никога не съм успявал да възпроизведа тази грешка. Получавам този регистър на сривовете чрез HockeyApp от природата ... така че се стремя да разреша това за нашите клиенти   -  person Joel Martinez    schedule 24.10.2012
comment
Кой ред е TheAppFeedController.m line 189?   -  person Joachim Isaksson    schedule 24.10.2012
comment
Това е странната част, 189 е затварящата скоба на метода removeAdView :-/   -  person Joel Martinez    schedule 24.10.2012

Отговори (1)


arrow_upward
1
arrow_downward 

[super removeAdView];
[self fixLayoutForAdRemoval:self.tableView];

Ако removeAdView разрушава части от себе си; ако причинява self да бъде освободен до точката на освобождаване, тогава последващото извикване на fixLayoutForAdRemoval: може лесно да се провали.

Включете откриването на зомбита в Инструменти и вижте какво открива.

person bbum    schedule 24.10.2012
comment
Останах с впечатлението, че viewDidUnload няма да бъде извикан след dealloc. Освен това zombies не разкри нищо ... не забравяйте, че не успях да възпроизведа това локално; то е открито само чрез докладване на дневник за сривове (hockeyapp) в производството. - person Joel Martinez; 24.10.2012
comment
Ааа -- Добре. Хм... с включена оптимизация, компилаторът понякога губи представа за номерата на редовете, следователно номерът на реда е изключен не е нечувано. Ако регистрационният файл за срив включва списък с динамични библиотеки в игра, проверете дали е на устройство с джейлбрейк. - person bbum; 24.10.2012
comment
Има ли конкретна библиотека, която трябва да търся, за да определя дали работи на джейлбрейкнато устройство? - person Joel Martinez; 24.10.2012
comment
Обикновено ще видите нещо като Cydia или libBac0n в списъка на dylib. Или библиотеки на странни места. - person bbum; 24.10.2012