2010-10-20 3 views
5

Я видел, что мое приложение вылетает при использовании с инструментом распределения. При просмотре журналов устройств я могу сказать, что это авария с «низкой памятью». Мой процесс приложения в дополнение к другим, используемым моим приложением, был отброшен. Вот как выглядят журналы устройство:Приложение вылетает при использовании с Allocations Instrument

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

Я не возникнут какие-либо сбои, когда приложение работает без инструментов и приложение воспринимаются пользователями как производительные. Я сосредоточен на решении этой проблемы в течение пары дней (почти весь мой код прокомментирован, чтобы найти проблему).

Мой вопрос: может ли приложение сбой при использовании в сочетании с инструментами представлять проблему конечному пользователю? Или это только вызовет проблемы при отладке памяти?

Примечание 1: Я не взаимодействую с приложением AT ALL при использовании его с инструментами. Он загружает контроллер вида, выполняет вызов службы aynch, который возвращает результаты, которые затем заполняются в два вида таблицы. Не много для освобождения, поскольку объекты все еще требуются.

Примечание 2: Ниже приведен фрагмент списков объектов LIVE из инструментов распределения (отсортированных по размеру в порядке убывания) при сбое приложения. Как вы можете видеть MYAPP это на самом деле не главный преступник (на первый взгляд)

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:] 

Благодаря

+0

, не видя своего кода, невозможно сделать что-либо со 100% уверенностью. –

+0

Что конкретно вы хотели бы видеть в коде? – amehta

ответ

0

У меня была аналогичная проблема раньше. Оказалось, что я использую неинициализированную память. Запуск с помощью Allocations изменил значение этой памяти, которое вызвало сбой.

+0

Как вы это узнали, был ли инструмент, который вы использовали? Когда инструменты падают, это не дает много полезной информации, поэтому я как бы застрял. – leetNightshade

Смежные вопросы