2015-06-09 5 views
3

Мы получили трассировку стека ниже от Flurry. Он был захвачен с устройства пользователя, и мы не можем его отслеживать. Он не перечисляет строки из нашей базы кода ... как мы можем устранить проблему с трассировкой стека и изолировать проблему?Трассировка стека отладки?

Полный Трассировка стека:

0 libGPUSupportMercury.dylib   0x34d068f6 <redacted> + 9 
1 IMGSGX535GLDriver     0x2f04050f <redacted> + 122 
2 GLEngine       0x32515a01 <redacted> + 172 
3 GLEngine       0x3251590f _gliPresentViewES + 134 
4 OpenGLES       0x325200cd <redacted> + 64 
5 SpriteKit       0x32990191 -[SKView _renderContent] + 1216 
6 libdispatch.dylib     0x3af1381f <redacted> + 22 
7 libdispatch.dylib     0x3af25dd7 <redacted> + 26 
8 SpriteKit       0x3298fca3 -[SKView renderContent] + 82 
9 SpriteKit       0x3298d633 <redacted> + 130 
10 SpriteKit       0x329b00eb -[SKDisplayLink _callbackForNextFrame:] + 254 
11 QuartzCore       0x32766df3 <redacted> + 98 
12 QuartzCore       0x32766b9d <redacted> + 344 
13 IOMobileFramebuffer     0x354df75d <redacted> + 104 
14 IOKit        0x30f69451 _IODispatchCalloutFromCFMessage + 248 
15 CoreFoundation      0x3023eef9 <redacted> + 136 
16 CoreFoundation      0x30249ab7 <redacted> + 34 
17 CoreFoundation      0x30249a53 <redacted> + 346 
18 CoreFoundation      0x30248227 <redacted> + 1398 
19 CoreFoundation      0x301b2f4f _CFRunLoopRunSpecific + 522 
20 CoreFoundation      0x301b2d33 _CFRunLoopRunInMode + 106 
21 GraphicsServices     0x350b7663 _GSEventRunModal + 138 
22 UIKit        0x32afe16d _UIApplicationMain + 1136 
23 <OurClassName>        0x000af494 __mh_execute_header + 345236 
24 libdyld.dylib      0x3af38ab7 <redacted> + 2 
+1

Это _too_ redacted! Это происходит, пока сцена спрайта работает. Вот и все. – matt

ответ

0

Во-первых, вам нужно получить базовый адрес для каждого из модулей, перечисленных в левой части (приложение, а также каждой системной библиотеки), из адресного пространства рандомизации (ASLR). Многие средства отчетов трассировки стека в приложении, такие как PLCrashReporter, могут хранить эту информацию в своем отчете.

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

Для системных библиотек символы отладки загружаются Xcode при первом подключении устройства к Xcode с использованием конкретной сборки ОС. Они хранятся в /Users/<yourusername>/Library/Developer/Xcode/iOS DeviceSupport/. Обратите внимание, что иногда версии ОС будут иметь несколько сборок (бета-версии или разные сборки для разных устройств); вам нужно получить сборку ОС, в которой произошел сбой, что означает, что трассировка стека также должна хранить эту информацию. Это также должна быть сборка ОС, которую видел ваш Xcode, иначе она не будет загружать информацию. Для системных модулей вы получите только имя функции, а не номер строки (что было бы бесполезно, так как они не являются открытым исходным кодом).

Затем вы можете использовать инструмент atos, указать ему адрес, адрес загрузки (базовый адрес неисправного модуля), архитектуру (для приложения, содержащего код для нескольких архитектур), и он будет выводить информацию о символе для этого адреса.

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