atos y dwarfdump no simbolizarán mi dirección

Recibí un informe de locking a través de AirBrake.io que no está simbólico. Dado que el informe del crash no está exactamente en el mismo formatting que un logging de errores de Apple, no puedo dejarlo en XCode como siempre, así que tomé exactamente la misma compilation de mi file XCode intentó simbolizarla en la command-line. Con el siguiente resultado:

$ atos -o kidsapp.app/kidsapp 0x0002fc4c 0x0002fc4c (in kidsapp) 

Estoy absolutamente seguro de que estoy usando la misma compilation de la que proviene el informe del crash. Entonces también intenté con dwarfdump:

 $ dwarfdump --lookup 0x0002fc4c --arch armv7 kidsapp.app.dSYM ---------------------------------------------------------------------- File: kidsapp.app.dSYM/Contents/Resources/DWARF/kidsapp (armv7) ---------------------------------------------------------------------- Looking up address: 0x000000000002fc4c in .debug_info... not found. Looking up address: 0x000000000002fc4c in .debug_frame... not found. 

Tampoco hay resultado ¿Hay algo más, además de usar el file dSYM incorrecto, que podría hacer mal? Sé que es el correcto ya que es la versión referida en el informe del crash en AirBrake y está en mi file XCode.

Cualquier ideas / consejos son bienvenidos!

Primero, compruebe si el dSYM es realmente el correcto para esa aplicación:

 dwarfdump --uuid kidsapp.app/kidsapp dwarfdump --uuid kidsapp.app.dSYM 

Ambos deben devolver el mismo resultado.

Luego verifica si el dSYM tiene algún contenido válido.

 dwarfdump --all kidsapp.app.dSYM 

Esto debería dar al less algo de información, que not found .

Supongo que el dSYM está corrupto. En general, es posible que desee utilizar un reportero de lockings que le brinde un informe de lockings completo con todos los subprocesss y la última información de retroceso de excepciones. Recomiendo usar algo basado en PLCrashReporter, por ejemplo, QuincyKit (Open Source SDK + Server + simbolización en tu Mac) o HockeyApp (Open Source SDK + Servicio de pago + simbología del lado del server) (Nota: ¡Soy uno de los desarrolladores!).

Utilicé la siguiente aritmética para resolverlo:

stack address + slideload address = symbol address

y

stack address es el valor hexadecimal que obtengo de mi informe de locking de volcado de stack (no un file .crash, solo el volcado de stack).

y

slide es el vmaddr del LC_SEGMENT cmd cuando se ejecuta otool -arch armv7 -l APP_BINARY_PATH . El mío generalmente termina siendo 0x00001000.

y

load address es la pieza complicada. En realidad, es la diferencia entre la dirección de la stack inferior de la cadena principal y la dirección PRIMERA de la parte de mi binary que contiene símbolos cuando se ejecuta dwarfdump --arch armv7 --all DSYM_BINARY_PATH . Esta es simplemente la dirección simbólica de la function main . Entonces, si la dirección más baja de su parte inferior es 0x8000 y la dirección simbólica de su function principal es 0x2000, entonces su load address es 0x6000.

Ahora con TODAS estas piezas puedo calcular la dirección del símbolo y ponerla en atos o dwarfdump: dwarfdump --lookup SYM_ADDR --arch armv7 APP_BINARY_PATH .

Ejemplo del volcado (puede ver que la load address era 0x00003af4):

----------------------------------------------------------------------

Archivo: /Users/user/Desktop/MyApp.xcarchive/dSYMs/MyApp.app.dSYM/Contents/Resources/DWARF/MyApp (armv7)

----------------------------------------------------------------------

0x00000024: [0x00003af4 – 0x00003b4e] main

0x00000098: [0x00003b50 – 0x00003d8c) – [Aplicación MyAppDelegate: didFinishLaunchingWithOptions:]

… el rest del vertedero

La parte más difícil fue darse count de que una de las 2 bibliotecas estáticas que había incluido tenía sus símbolos despojados antes de ser un enlace al binary de mi aplicación. Eso dejó un ENORME espacio de direcciones de símbolos, así que solo terminé con dos tercios de los símbolos que necesitaba en mi dSYM.

Asegúrese de que los siguientes indicadores estén configurados como NO en su proyecto xcode de bibliotecas estáticas, de modo que cuando se establezca un enlace en contra de este, puede insert los símbolos en el binary de su aplicación (que posteriormente se puede despojar): COPY_PHASE_STRIP , DEAD_CODE_STRIPPING y STRIP_INSTALLED_PRODUCT .

Ahora puede preguntar: "¿qué hago si el volcado de la stack no incluye la function principal, ya que no está en el hilo principal para que no pueda get la dirección de stack de la function principal?". A eso respondería: "¡No tengo ni idea!". Simplemente cruce los dedos y espere que pueda get una traza de stack que incluya la dirección de símbolo o use un sistema de reporte de fallas que imite los loggings de fallas de Apple, como PLCrashReporter.

[EDITAR el 26 de mayo de 2013] –

Me llamó la atención que la load address es realmente la dirección del binary mach-o. Aunque lo que describí anteriormente a menudo puede funcionar, en realidad no es correcto. Esto se puede get a través del CRASH REPORT, pero el objective de esta respuesta fue proporcionar los símbolos de un crash cuando no tiene un informe de crash. La mejor manera en la que he llegado a averiguar la load address cuando quiero simbolizar es asegurándome de registrar la load address con las stack addresses la stack addresses .

Personalmente, he creado un sistema para registrar lockings (no informes de lockings) y enviarlos a un cubo S3 donde puedo recuperarlos más tarde para depurarlos. Cuando inicio mi aplicación, almaceno en caching la slide , la load address y la load address la main function address para usar si mi aplicación falla y envío las stack addresses la stack addresses .

NOTA: las funciones dyld usan #include <mach-o/dyld.h>

slide = la dirección devuelta por _dyld_get_image_vmaddr_slide(0)

load address = la dirección devuelta por _dyld_get_image_header(0)

main function address = la última dirección en [NSThread callStackReturnAddresses] cuando se llama al hilo principal

En el momento del locking, estoy seguro de registrar [NSThread callStackReturnAddresses] y [NSThread callStackSymbols] , así como la architecture que se puede recuperar al tener este método:

 - (NSString*) arch { NSString* arch = #ifdef _ARM_ARCH_7 @"armv7"; #elif defined (_ARM_ARCH_6) @"armv6"; #else nil; #endif return arch; } 

Aún no sé cómo diferenciar armv7 y armv7s.

Entonces esto puede ayudar en el futuro. Planeo tomar todo lo que he aprendido y convertir esto en una simple herramienta de locking, mejor que la herramienta natos (probablemente natos v2).

He actualizado natos para admitir el suministro manual de la load address : https://github.com/NSProgrammer/natos

Para aquellos que ciertas veces no tienen el valor para Load Address así:

 Jan 14 11:02:39 Dennins-iPhone AppName[584] <Critical>: Stack Trace: ( 0 CoreFoundation 0x2c3084b7 <networkingacted> + 150 1 libobjc.A.dylib 0x39abec8b objc_exception_throw + 38 2 CoreFoundation 0x2c21cc35 CFRunLoopRemoveTimer + 0 3 AppName 0x0005a7db AppName + 272347 

He creado un bash simple para ayudarme a depurar:

 #! /bin/bash read -p "[Path] [App Name] [Stack Address] [Relative Address] " path appName runtimeAddress relativeAddress loadAddress=`echo "obase=16;ibase=10;$((runtimeAddress-relativeAddress))" | bc` atos -o $path/Payload/$appName.app/$appName -l $loadAddress $runtimeAddress -arch armv7 

Simplemente lee la ruta de la aplicación, el nombre de la aplicación, la dirección de time de ejecución y el valor después de la señal "+" (el valor decimal) y luego encuentra el valor de la dirección de carga para ejecutar el command atos.

Creo que esta publicación puede ayudarte, https://stackoverflow.com/a/12559150/1773317 . El compromiso de Joe solucionó mi problema.

La razón es que mis files .app y .dSYM no se pueden indexar por foco, por lo que mi XCode no puede simbolizar correctamente la información del error.

Intereting Posts