Simbolización de informes de locking de aplicaciones de iPhone

Estoy tratando de probar y simbolizar los informes de fallas de mi aplicación de iPhone.

Recuperé los informes de fallos de iTunes Connect. Tengo el binary de la aplicación que envié a la App Store y tengo el file dSYM que se generó como parte de la compilation.

Tengo todos estos files juntos dentro de un único directory indexado por la atención.

¿Ahora que?

He intentado invocar:

symbolicatecrash crashreport.crash myApp.app.dSYM 

y solo muestra el mismo text que se encuentra en el informe del crash para comenzar, no simbolizado.

¿Estoy haciendo algo mal?

Cualquier ayuda sería muy apreciada, gracias.

Pasos para analizar el informe de locking de Apple:

  1. Copie el file .app de lanzamiento que se envió a la tienda de aplicaciones, el file .dSYM que se creó en el momento de la publicación y el informe de locking se recibe de APPLE en una FOLDER .

  2. OPEN la aplicación de terminal y vaya a la carpeta creada anteriormente (usando el command cd )

  3. Ejecute atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH . La location de la memory debe ser la que bloqueó la aplicación según el informe.

atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508 : atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508

Esto le mostrará la línea exacta, el nombre del método que resultó en un locking.

Ej: [classname functionName:]; -510 [classname functionName:]; -510

Simbolizando IPA

si usamos IPA para simbolizar: simplemente cambie el nombre de la extensión .ipa con .zip, extráigalo y podemos get una Carpeta de Carga útil que contenga la aplicación. En este caso, no necesitamos el file .dSYM.

Nota

Esto solo puede funcionar si el binary de la aplicación no tiene símbolos despojados. De forma pnetworkingeterminada, las comstackciones de versiones despojaron los símbolos. Podemos cambiarlo en la configuration de construcción del proyecto "Eliminar símbolos de debugging durante la copy" en NO.

Más detalles ver esta publicación

Después de leer todas estas respuestas aquí para simbolizar un logging de locking (y finalmente tener éxito), creo que hay algunos puntos que faltan aquí que son realmente importantes para determinar por qué la invocación de symbolicatecrash no produce un resultado simbólico.

Hay tres activos que deben encajar cuando se simboliza un logging de locking:

  1. El file de logging de locking en sí (por ejemplo, example.crash ), ya sea exportado desde el organizador de XCode o recibido de iTunes Connect.
  2. El package .app (es decir, example.app ) que contiene el binary de la aplicación que pertenece al logging de .app . Si tiene un package .ipa (es decir, example.ipa ), puede extraer el package .app descomprimiendo el package .ipa (es decir, unzip example.ipa ejemplo .ipa ). Luego, el package .app reside en la Payload/ carpeta extraída.
  3. El package .dSYM que contiene los símbolos de debugging (es decir, example.app.dSYM )

Antes de comenzar a simbolizar, debe verificar si todos los artefactos coinciden, lo que significa que el logging de locking pertenece al binary que tiene y que los símbolos de debugging son los que se producen durante la creación de ese binary.

Cada binary es referido por un UUID que se puede ver en el file de logging de lockings:

 ... Binary Images: 0xe1000 - 0x1f0fff +example armv7 <aa5e633efda8346cab92b01320043dc3> /var/mobile/Applications/9FB5D11F-42C0-42CA-A336-4B99FF97708F/example.app/example 0x2febf000 - 0x2fedffff dyld armv7s <4047d926f58e36b98da92ab7a93a8aaf> /usr/lib/dyld ... 

En este extracto, el logging de locking pertenece a una image binaria de la aplicación llamada example.app/example con UUID aa5e633efda8346cab92b01320043dc3 .

Puede verificar el UUID del package binary que tiene con dwarfdump:

 dwarfdump --uuid example.app/example UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app/example 

Luego, debe verificar si los símbolos de debugging también pertenecen a ese binary:

 dwarfdump --uuid example.app.dSYM UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app.dSYM/Contents/Resources/DWARF/example 

En este ejemplo, todos los activos encajan entre sí y debería poder simbolizar su stacktrace.

Continuando con el script symbolicatecrash :

En Xcode 8.3 debería poder invocar el script a través de

 /Applications/Xcode.app/Contents/ShanetworkingFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v example.crash 2> symbolicate.log 

Si no está allí, puede ejecutar un find . -name symbolicatecrash find . -name symbolicatecrash en su directory XCode.app para encontrarlo.

Como puede ver, no hay más parameters dados. Por lo tanto, el script debe encontrar los símbolos binarys y de debugging de la aplicación al ejecutar una búsqueda de foco. Busca los símbolos de debugging con un índice específico llamado com_apple_xcode_dsym_uuids . Puede realizar esta búsqueda usted mismo:

 mdfind 'com_apple_xcode_dsym_uuids = *' 

resp.

 mdfind "com_apple_xcode_dsym_uuids == AA5E633E-FDA8-346C-AB92-B01320043DC3" 

La primera invocación de Spotlight le proporciona todos los packages dSYM indexados y el segundo le proporciona los packages .dSYM con un UUID específico. Si .dSYM no encuentra su package .dSYM , entonces symbolicatecrash no funcionará. Si haces todas estas cosas, por ejemplo, en una subcarpeta de tu ~/Desktop spotlight debería poder encontrarlo todo.

Si symbolicatecrash encuentra su package .dSYM , debería haber una línea como la siguiente en symbolicate.log :

 @dsym_paths = ( <SOME_PATH>/example.app.dSYM/Contents/Resources/DWARF/example ) 

Para encontrar su package .app , una búsqueda de foco similar a la siguiente es invocada por symbolicatecrash :

 mdfind "kMDItemContentType == com.apple.application-bundle && (kMDItemAlternateNames == 'example.app' || kMDItemDisplayName == 'example' || kMDItemDisplayName == 'example.app')" 

Si symbolicatecrash encuentra su package .app , debería aparecer el siguiente extracto en symbolicate.log :

 Number of symbols in <SOME_PATH>/example.app/example: 2209 + 19675 = 21884 Found executable <SOME_PATH>/example.app/example -- MATCH 

Si todos esos resources son encontrados por symbolicatecrash , debería imprimir la versión simbólica de su logging de fallas.

Si no, puede pasar sus files dSYM y .app directamente.

 symbolicatecrash -v --dsym <SOME_PATH>/<App_URI>.app.dSYM/<APP_NAME>.app.dsym <CRASHFILE> <SOME_OTHER_PATH>/<APP_NAME>.app/<APP_NAME> > symbolicate.log 

Nota: La traza inversa simbólica se enviará al terminal, no a symbolicate.log .

Con la última versión de Xcode (3.2.2), puede drag and drop cualquier informe de fallas en la sección Registros de dispositivos de Xcode Organizer y automáticamente se simbolizarán por usted. Creo que esto funciona mejor si construiste esa versión de la aplicación usando Build & Archive (también parte de Xcode 3.2.2)

Lo hice con éxito, ahora quiero compartirlo con todos ustedes.

Estos son los siguientes pasos:

Paso 1: Crea una carpeta en el escritorio, dale un nombre a "CrashReport" y coloca tres files ("MYApp.app", "MyApp.app.dSYM", "MYApp_2013-07-18.crash") en él.

Paso 2: abra el buscador y vaya a Aplicaciones, donde encontrará la aplicación Xcode, haga clic derecho sobre esto y click "Mostrar contenido del package", luego de seguir este path simple

"Contenido-> Desarrollador-> Plataforms-> iPhoneOS.platform-> Desarrollador-> Biblioteca-> Marco Privado- > DTDeviceKit.framework -> Versiones-> A-> Recursos"

O

"Contenido-> Desarrollador-> Plataforms-> iPhoneOS.platform-> Desarrollador-> Biblioteca-> Marco Privado- > DTDeviceKitBase.framework -> Versiones-> A-> Recursos"

O

Para Xcode 6 y superior la ruta es Aplicaciones / Xcode.app / Contents / ShanetworkingFrameworks / DTDeviceKitBase.framework / Versions / A / Resources

Donde encuentre el file "symbolicatecrash", copie esto y péguelo en la carpeta "CrashReport".

Paso 3: inicie el terminal, ejecute estos 3 commands

  1. cd / Users / mac38 / Desktop / CrashReport y presiona el button Entrar

  2. export DEVELOPER_DIR = "/ Applications / Xcode.app / Contents / Developer" y presiona Enter

  3. ./symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYM y presiona Enter Now its Done … (NOTA: las versiones de alnetworkingedor de 6.4 o posterior no tienen la opción -A, simplemente déjenla fuera)

Happy Coding … Gracias

Utilizo Airbrake en mis aplicaciones, lo que hace un buen trabajo de logging remoto de errores.

He aquí cómo los simbolizo con atos si la traza trasera lo necesita:

  1. En Xcode (4.2) vaya al organizador, haga clic derecho en el file desde el cual se generó el file .ipa.

  2. En Terminal, cd en xcarchive por ejemplo MyCoolApp 10-27-11 1.30 PM.xcarchive

  3. Ingrese los siguientes atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp' (no olvide las comillas simples)

  4. No incluyo mi símbolo en esa llamada. Lo que obtienes es un cursor de bloque en una línea vacía.

  5. Luego copio / pego mi código de símbolo en ese cursor de bloque y presiono enter. Verás algo como:

    -[MyCoolVC dealloc] (in MyCoolApp) (MyCoolVC.m:34)

  6. Regresó a un cursor de bloque y puede pegar otros símbolos.

Ser capaz de atravesar su traza atrás un artículo sin volver a ingresar al primer bit es un buen ahorro de time.

¡Disfrutar!

También puse dsym, package de aplicaciones y logging de lockings en el mismo directory antes de ejecutar el locking simbólico.

Luego utilizo esta function definida en mi .profile para simplificar ejecutar symbolicatecrash:

 function desym { /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more } 

Los arguments agregados allí pueden ayudarlo.

Puede verificar para asegurarse de que el proyector "ve" sus files dysm ejecutando el command:

 mdfind 'com_apple_xcode_dsym_uuids = *' 

Busque el dsym que tiene en su directory.

NOTA: A partir del último Xcode, ya no hay un directory de desarrolladores. Puede encontrar esta utilidad aquí:

/Applications/Xcode.app/Contents/ShanetworkingFrameworks/DTDeviceKitBase.framework/Vers ions / A / Resources / symbolicatecrash

Solo una respuesta simple y actualizada para xcode 6.1.1.

PASOS

1.Xcode> Ventana> Dispositivos.

2. Seleccione un dispositivo de una list de dispositivos en la sección DISPOSITIVOS.

3. Seleccione Ver loggings de dispositivo.

4. En la sección Todos los loggings, puede arrastrar directamente soltar el informe.

5.Xcode automáticamente simbolizará el informe del crash por usted.

6. Puede encontrar el informe del crash simbólico haciendo coincidir su date / hora con la date / hora mencionada en su informe del crash.

A pesar de que había estado desarrollando aplicaciones desde hace algunos años, esta fue la primera vez que depuré un binary y me sentí como un completo NOOB descubriendo dónde estaban todos los files, es decir, ¿dónde está * .app * .dSYM y los loggings de fallas? Tuve que leer varias publicaciones para resolverlo. La image vale más que mil palabras y espero que esta publicación ayude a cualquier otra persona en el futuro.

1- Primero ve a itunesconnect y descarga tus loggings de fallas. NOTA: En la mayoría de los casos, puede get algo como "Se han enviado demasiados informes para que se muestre un informe". Básicamente, no hay suficientes usuarios que hayan enviado informes de logging de lockings a Apple, en cuyo caso no puede hacer mucho en ese momento.

introduzca la descripción de la imagen aquí

introduzca la descripción de la imagen aquí

2- Ahora bien, si no hubiera cambiado su código ya que había enviado su file binary a Apple, entonces inicie Xcode para ese proyecto y vuelva a hacer Producto -> Archivo. De lo contrario, solo busque su último binary enviado y haga clic derecho sobre él.

introduzca la descripción de la imagen aquí

introduzca la descripción de la imagen aquí

introduzca la descripción de la imagen aquí

introduzca la descripción de la imagen aquí

Pasos para simbolizar un informe de locking automáticamente usando XCode:

  1. Conecte un dispositivo iOS a su Mac (sí, uno físico, sí, sé que es estúpido)

  2. Elija "Dispositivos" en el menu "Ventana" introduzca la descripción de la imagen aquí

  3. Haga clic en su dispositivo a la izquierda y VER REGISTROS DE DISPOSITIVOS a la derecha introduzca la descripción de la imagen aquí

  4. Espere. Puede demorar un minuto en aparecer. Tal vez, hacer Command-A luego Delete lo acelerará.

  5. Paso indocumentado crítico: cambie el nombre del informe de locking que recibió de iTunesConnect desde la extensión .txt extensión .crash

  6. Arrastre el informe de locking a esa área a la izquierda introduzca la descripción de la imagen aquí

Y luego Xcode simbolizará el informe del crash y mostrará los resultados.

Fuente: https://developer.apple.com/library/ios/technotes/tn2151/_index.html

Usando XCode 4, la tarea es aún más simple:

  • Organizador abierto,
  • click la biblioteca | Dispositivo Inicie session en la columna izquierda
  • Haga clic en el button "Importar" en la parte inferior de la pantalla …

y voilà El file de logging se importa y se simboliza automáticamente para usted. Siempre que archivó la compilation usando XCode -> Producto -> Archive primero

En XCode 4.2.1, abre Organizador, luego ve a Biblioteca / Registros de dispositivos y arrastra tu file .crash a la list de loggings de fallas. Será simbólico para ti después de unos segundos. Tenga en count que debe utilizar la misma instancia de XCode en la que se archivó la compilation original (es decir, el file para su compilation debe existir en el Organizador).

El Organizador mágico XCode no es tan mágico sobre la simbología de mi aplicación. No recibí símbolos en absoluto por los informes de fallos que recibí de Apple de una presentación de aplicaciones fallida.

Intenté usar la línea de command, poniendo el informe de locking en la misma carpeta que el file .app (que envié a la tienda) y el file .dSYM:

 $ symbolicatecrash "My App_date_blahblah-iPhone.crash" "My App.app" 

Esto solo proporcionó símbolos para mi aplicación y no el código básico de la base, pero fue mejor que el número que me da Organizador y fue suficiente para encontrar y corregir el locking que tuvo mi aplicación. Si alguien sabe cómo extender esto para get símbolos de la Fundación, sería de agradecer.

En mi caso, estaba arrastrando informes de fallas directamente desde el correo al organizador. Por alguna razón, eso evitó que los informes de fallas se simbolicen (me encantaría saber por qué).

Al copyr primero los informes de fallos en el escritorio y luego arrastrarlos desde allí hasta el organizador, se los simbolizó correctamente.

Caso muy específico, lo sé. Pero pensé que lo compartiría por si acaso.

Aquí hay otro problema que tengo con symbolicatecrash: no funcionará con aplicaciones que tengan espacios en su package (es decir, 'Test App.app'). Tenga en count que no creo que pueda tener espacios en su nombre al enviar, así que debe eliminarlos de todos modos, pero si ya tiene lockings que necesitan ser analizados, parche symbolicatecrash (4.3 GM) como tal:

 240c240 < my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == $exec_name.app\""; --- > my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == '$exec_name.app'\""; 251c251 < my $cmd = "find \"$archive_path/Products\" -name $exec_name.app"; --- > my $cmd = "find \"$archive_path/Products\" -name \"$exec_name.app\""; 

Para aquellos que usan Airbrake, hay una respuesta sólida arriba pero no funcionaría para mí sin ajustes:

Funciona para algunas direcciones de memory pero no para otras, no estoy seguro de por qué …

  • Cree un directory nuevo en el escritorio o donde sea
  • Buscar file en cuestión en el organizador Xcode
  • Doble toque para revelar en el buscador
  • Toca dos veces para mostrar los contenidos del package.
  • Copie el file .dSYM y el file .app en un nuevo directory.
  • cd en nuevo directory
  • Ejecute este command: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo'
  • La terminal ingresará a un movimiento interactivo
  • Pegue en la dirección de la memory y presione Enter, emitirá el nombre del método y el número de línea
  • Como alternativa, ingrese este command: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo' Para get información para una sola dirección

La combinación que funcionó para mí fue:

  1. Copie el file dSYM en el directory donde se encontraba el informe de locking.
  2. Descomprima el file ipa que contiene la aplicación ('descomprimir MyApp.ipa')
  3. Copie el binary de la aplicación de la carga útil explosionada resultante en la misma carpeta que el informe de lockings y el file de símbolos (Algo así como "MyApp.app/MyApp")
  4. Importe o re-simbólica el informe de lockings desde el organizador de XCode

Al usar atos , no pude resolver la información de símbolo correcta con las direcciones y las correcciones que estaban en el informe de locking. Cuando hice esto, veo algo más significativo, y parece ser un rastro de stack legítimo.

Tuve que hacer un montón de piratería del script symbolicatecrash para que funcione correctamente.

Por lo que puedo decir, symbolicatecrash ahora requiere que .app esté en el mismo directory que .dsym. Utilizará el .dsym para localizar el .app, pero no usará el dsym para encontrar los símbolos.

Debe hacer una copy de su symbolicatecrash antes de intentar estos parches que lo harán ver en el dsym:

Alnetworkingedor de la línea 212 en la function getSymbolPathFor_dsymUuid

 212 my @executablePath = grep { -e && ! -d } glob("$dsymdir" . "/Contents/Resources/DWARF/" . $executable); 

Alnetworkingedor de la línea 265 en la function matchesUUID

 265 return 1; 

Esto es simple, después de search mucho he encontrado pasos claros para simbolizar todo el file de logging de lockings.

  • Copie los files .app, crash_report y DSYM en una carpeta.
  • conecte el dispositivo con xcode
  • Luego vaya a la window -> select dispositivos -> vea los loggings del dispositivo
  • Luego select este dispositivo, elimine todos los loggings.
  • arrastre y suelte su locking en la sección de logging del dispositivo. Simbolizará automáticamente el locking. simplemente haga clic derecho en el informe y exportarlo.

feliz encoding,
Riyaz

Para simbolizar los lockings, Spotlight debe poder encontrar el file .dSYM que se generó al mismo time que el binary que envió a Apple. Dado que contiene la información del símbolo, no tendrá suerte si no está disponible.

Me puse un poco gruñón sobre el hecho de que nada aquí parece "simplemente funciona", así que hice algunas investigaciones y el resultado es:

Configuración: QuincyKit back end que recibe informes. No se estableció ninguna simbología ya que ni siquiera podía comenzar a descubrir qué estaban sugiriendo que hago para que funcione.

La solución: download informes de fallos del server en línea. Se llaman 'crash' y, por defecto, entran en la carpeta ~ / Downloads /. Teniendo esto en count, este script "hará lo correcto" y los informes de fallas se includeán en Xcode (Organizador, loggings de dispositivos) y se realizará simbología.

El guión:

 #!/bin/bash # Copy crash reports so that they appear in device logs in Organizer in Xcode if [ ! -e ~/Downloads/crash ]; then echo "Download a crash report and save it as $HOME/Downloads/crash before running this script." exit 1 fi cd ~/Library/Logs/CrashReporter/MobileDevice/ mkdir -p actx # add crash report to xcode abbreviated cd actx datestr=`date "+%Y-%m-%d-%H%M%S"` mv ~/Downloads/crash "actx-app_"$datestr"_actx.crash" 

Las cosas se pueden automatizar a dónde puede drag and drop en Xcode Organizer haciendo dos cosas si usa QuincyKit / PLCR.

En primer lugar, debe editar el script remoto admin / actionapi.php ~ line 202. No parece tener la timestamp correcta, por lo que el file termina con el nombre 'crash' que Xcode no reconoce (quiere algo punto de falla):

 header('Content-Disposition: attachment; filename="crash'.$timestamp.'.crash"'); 

En segundo lugar, en el lado iOS en QuincyKit BWCrashReportTextFormatter.m ~ línea 176, cambia @"[TODO]" a @"TODO" para sortear los malos caracteres.

atos está siendo desaprobado, por lo que si está ejecutando OSX 10.9 o posterior, es posible que necesite ejecutar

xcrun atos

Advertencia: / usr / bin / atos se está moviendo y se eliminará de una futura versión de OS X. Ahora está disponible en las herramientas de desarrollador de Xcode para invocarse a través de: xcrun atos

Me gusta usar Textwrangler para identificar errores en el rechazo binary de una aplicación original. (Los datos del locking se encontrarán en su count de iTunesConnect). Utilizando el método de Sachin anterior, copio el original.crash a TextWrangler, y luego copio el file symbolicatecrash que he creado a otro file TextWrangler. Al comparar los dos files se señalan las diferencias. El file symbolicatecrash tendrá diferencias que señalarán el file y el número de líneas de problemas.

Prefiero un script que simbolice todos mis loggings de locking.

Condiciones previas

Crea una carpeta y coloca 4 cosas:

  1. script symbolicatecrash perl: hay muchas respuestas SO que le dicen a su location

  2. El file de la compilation que coincide con los lockings (de Xcode Organizer. Simple como Show in Finder y copyr) [No estoy seguro de que esto sea necesario]

  3. Todos los packages de xccrashpoint (desde Xcode Organizer. Show in Finder , puede copyr todos los packages en el directory o el único xccrashpoint que desea simbolizar)

  4. Agregue ese script corto al directory:

     #!/bin/sh echo "cleaning old crashes from directory" rm -P *.crash rm -P *.xccrashpoint rm -r allCrashes echo "removed!" echo "" echo "--- START ---" echo "" mkdir allCrashes mkdir symboledCrashes find `ls -d *.xccrashpoint` -name "*.crash" -print -exec cp {} allCrashes/ \; cd allCrashes for crash in *.crash; do ../symbolicatecrash $crash > ../symboledCrashes/V$crash done cd .. echo "" echo "--- DONE ---" echo "" 

El guión

Cuando ejecute el script, obtendrá 2 directorys.

  1. allCrashes : todos los lockings de todo el xccrashpoint estarán allí.

  2. symboledCrashes – los mismos crashs pero ahora con todos los símbolos.

  3. NO necesita limpiar el directory de lockings anteriores antes de ejecutar el script. se limpiará automáticamente. ¡buena suerte!