2010-10-20 13 views
5

Widziałem, że moja aplikacja ulega awarii, gdy jest używana z Instrumentem alokacji. Patrząc na logi urządzeń, mogę stwierdzić, że jest to awaria "Niska pamięć". Mój proces aplikacji oraz inne używane przez moją aplikację zostały odrzucone. Oto jak dzienniki urządzeń wyglądać:Awaria aplikacji po użyciu z Instrumentem Przydziału

MyAPP <09da004ccd82e7a2c54e0ea6ab4eab24> 1990 (jettisoned) (active) 
MobilePhone <6d3241e15be58311a76700272febc6d4>  635 (jettisoned) 
    accessoryd <6a25188f645a24b167cda5e0a86d486a>  121 (jettisoned) 

I nie napotykają żadnych awarii, gdy aplikacja jest uruchomiona bez instrumentów, a aplikacja jest postrzegane przez użytkowników za wydajnych. Koncentruję się na rozwiązaniu tego problemu przez kilka dni (prawie cały mój kod jest komentowany, aby znaleźć problem).

Moje pytanie brzmi - Czy aplikacja, która ulegnie awarii w połączeniu z instrumentami, może stanowić problem dla użytkownika końcowego? Czy może to tylko powodować problemy podczas debugowania problemów z pamięcią?

Uwaga 1: W ogóle nie wchodzę w interakcję z aplikacją podczas używania jej z instrumentami. Ładuje kontroler widoku, wykonuje wywołanie usługi asynchronicznej, które zwraca wyniki, które następnie są zapełniane dwoma widokami tabeli. Nie za dużo, aby zwolnić, ponieważ obiekty są nadal wymagane.

Uwaga 2: Oto fragment LIVE list obiektów z Instrumentów Przydziału (posortowane według wielkości w kolejności) po awarii aplikacji. Jak widać MojaApl nie jest to główny sprawca (pozornie)

Size(bytes) Responsible Library Responsible Caller 
131072 UIKit -[UIView(Internal) _subclassImplementsDrawRect] 
45056 CoreGraphics  zone_malloc 
16384 libCGFreetype.A.dylib ft_allocate 
11264 Foundation NSPopAutoreleasePool 
8192 libCGFreetype.A.dylib ft_allocate 
8192 Foundation NSLogv 
7680 libCGFreetype.A.dylib ft_allocate 
7680 libCGFreetype.A.dylib ft_allocate 
7680 CoreGraphics argb32_mark_constmask 
5120 CoreGraphics CGDataProviderCreateWithCopyOfData 
4608 libCGFreetype.A.dylib ft_allocate 
4608 libCGFreetype.A.dylib ft_allocate 
4608 libCGFreetype.A.dylib ft_allocate 
4096 libSystem.B.dylib __stack_chk_fail 
4096 QuartzCore CA::Transaction::create() 
4096 Foundation NSPushAutoreleasePool 
4096 MYAPP -[CJSONScanner scanNotQuoteCharactersIntoString:] 

Dzięki

+0

nie widząc kodu, nie można uzyskać niczego z 100% pewnością. –

+0

co konkretnie chciałbyś zobaczyć w kodzie? – amehta

Odpowiedz

0

miałem podobny problem wcześniej. Okazało się, że używałem niezainicjowanej pamięci. Uruchomienie z alokacjami zmieniło wartość pamięci, która spowodowała awarię.

+0

Jak to odkryłeś, czy było jakieś narzędzie, którego użyłeś? Kiedy Instruments ulega awarii, nie dostarcza dokładnych informacji, więc utknąłem. – leetNightshade

Powiązane problemy