iPhone Crash с «No Backtrace»

Question

Мое приложение для iPhone недавно было отклонено из App Store «потому что он падает при запуске». Однако я не могу воспроизвести этот крах. Приложение прекрасно работает как на симуляторе, так и на устройстве с тем же аппаратным и программным обеспечением, на котором Apple тестировала его (iPhone 3.1, работающий под управлением iOS 4). Аварийные журналы, которые они мне прислали, говорят «Нет возврата назад», поэтому мне нечего искать в моем коде. Вот пример:

Incident Identifier: [...] 
CrashReporter Key: [...] 
Hardware Model:  iPhone3,1 
Process:   [MyApp] [1172] 
Path:   /var/mobile/Applications/[...]-3F1B-4504-A572-[...]/[MyApp].app/[MyApp] 
Identifier:  [MyApp] 
Version:   ??? (???) 
Code Type:  ARM (Native) 
Parent Process: launchd [1] 

Date/Time:  2010-07-08 [...] 
OS Version:  iPhone OS 4.0 (8A293) 
Report Version: 104 

Exception Type: EXC_BAD_ACCESS (SIGSEGV) 
Exception Codes: KERN_INVALID_ADDRESS at 0xfe42c648 
Highlighted Thread: 0 

Backtrace not available 

Unknown thread crashed with ARM Thread State: 
    r0: 0x00002388 r1: 0x00000000  r2: 0x3e2b47c8  r3: 0x00000108 
    r4: 0x2fe00000 r5: 0x00000000  r6: 0x00000000  r7: 0x00000000 
    r8: 0x2ffffb48 r9: 0x2fffecfc  r10: 0x00000000  r11: 0x00000000 
    ip: 0x00000010 sp: 0x2ffffb4c  lr: 0x2fe08907  pc: 0xfe42c648 
    cpsr: 0x40000010 

Binary Images: 
    0x1000 - 0x78fff +[MyApp] armv7 <23af3d265c3086eaceb51cc649eb794f> /var/mobile/Applications/[...]-3F1B-4504-A572-[...]/[MyApp].app/[MyApp] 
0x2fe00000 - 0x2fe26fff dyld armv7 <697ae459733a7f0b6c439b21ba62b110> /usr/lib/dyld 
[many more libraries...] 

Как я могу начать отлаживать это? Возможно ли, что это проблема сборки, а не ошибка кодирования? И могу ли я извлечь какую-либо полезную информацию из частей «Состояние ARM-потока» или «Двоичные изображения» в отчете о сбое?

Спасибо!

* обновление: * Я установил приложение впервые на другой iPhone под управлением iOS 4 и по-прежнему не может воспроизвести сбой. Я начинаю думать, что это проблема с параметрами времени сборки, такими как библиотеки или целевые версии. Основываясь на отчете о сбое, возможно ли, что какой-либо код моего приложения был выполнен?

Answer 1

Я так и не смог воспроизвести авария. Я перепутал несколько параметров сборки и повторно представил и был одобрен.

Answer 2

Segfault вряд ли будет ошибкой сборки. Чтобы воспроизвести эту проблему, попробуйте очистить любую сохраненную информацию на симуляторе iPhone перед запуском проекта; возможно, что вы предполагаете наличие определенных записей в NSUserDefaults, которые присутствуют на вашем собственном iPhone, но которые не будут доступны при установке по умолчанию. Если это не повторяет проблему, вы должны создать модульные тесты для каждого из ваших компонентов, исключая каждый компонент за раз в качестве причины сбоя. В конце концов, вы исключите каждую причину неудачи, кроме истинной причины неудачи.

Answer 3

См. Technical Note TN2151:Understanding and Analyzing iPhone OS Application Crash Reports. Символирование, как правило, поможет вам отследить источник сбоя, но поскольку в этом случае он не может помочь, это не поможет.

Не утруждайте себя тестированием на тренажере. Сборка симулятора и сборка устройства представляют собой совершенно отдельные компиляции для двух разных аппаратных средств. Просто потому, что он работает на симуляторе, ничего не говорит о сбое на устройстве.

Помните, что Apple будет испытывать стресс при тестировании, выполняя такие действия, как запуск на iOS4 с другими приложениями, которые потребляют большую часть памяти. Вам нужно будет это сделать и на вашем тестовом устройстве.

Вам, скорее всего, придется стереть ваше тестовое устройство обратно по умолчанию, чтобы воспроизвести тест, который делает Apple. Затем откройте все возможные приложения, прежде чем запускать свои собственные.

Answer 4

Вы можете сделать некоторую информацию из состояния резьбы ARM. Регистр ПК является единственным, в котором содержится недопустимый адрес, о котором сообщается в отчете о сбое. Это означает, что ваше приложение попыталось выполнить код по этому адресу.

SIGSEGV означает, что указанный адрес недействителен. В системе нет страниц памяти с этим адресом.

Я не думаю, что iOS позволит вам просто выполнить код с любого адреса, но возможно, что фрейм стека был поврежден, а возвращаемый адрес был недопустим при возврате функции. Это поддерживает проблему «backtrace not available».

Загрязнение стека может быть результатом переполнения буфера. Если вы используете memcpy или цикл наборов в локальном массиве переменных и переполняете конец массива, вы можете уничтожить стек.