Informes de fallos de iOS: atos no funciona como se esperaba

Estoy viendo un informe de fallas proporcionado por Apple

Hardware Model: iPhone4,1 Version: ??? (???) Code Type: ARM (Native) Parent Process: launchd [1] Date/Time: 2012-11-18 16:03:44.951 -0600 OS Version: iOS 6.0.1 (10A523) Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x51fe5264 Crashed Thread: 0 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libobjc.A.dylib 0x352925b0 objc_msgSend + 16 1 MYAPP 0x0006573a -[MyViewController(Images) didReceiveImage:context:etag:expires:] + 42 2 MYAPP 0x0004fb26 -[MyImageTask didReceiveImage:] + 98 3 Foundation 0x361ac8e8 __NSThreadPerformPerform 4 CoreFoundation 0x3b37d680 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 5 CoreFoundation 0x3b37cee4 __CFRunLoopDoSources0 6 CoreFoundation 0x3b37bcb2 __CFRunLoopRun 7 CoreFoundation 0x3b2eeeb8 CFRunLoopRunSpecific 8 CoreFoundation 0x3b2eed44 CFRunLoopRunInMode 9 GraphicsServices 0x396bc2e6 GSEventRunModal 10 UIKit 0x3452e2f4 UIApplicationMain 11 MYAPP 0x0004934a main + 70 12 MYAPP 0x000492fc start + 36 

Lo curioso es que cuando uso atos para buscar la línea de código que corresponde a las ubicaciones de dirección 0x0006573a y 0x0004fb26 obtengo una coincidencia completamente diferente. La salida atos ni siquiera es de la misma clase que se menciona en el registro de locking (MyViewController, MyImageTask). En cambio, atos me señala líneas de código totalmente benignas en una clase completamente no relacionada. Verifiqué una vez más que estoy trabajando con el dSYM e IPA exacto que envié a Apple.

Mi comando atos

 /Applications/Xcode.app/Contents/Developer/usr/bin/atos -arch armv7 -o MYAPP.app/MYAPP 0x0004fb26 

El mismo resultado con / usr / bin / atos y para armv7s.

¿Alguien más ha tenido este problema? ¿Puede aconsejarme? Gracias.

Tienes que calcular la dirección para usar con atos, no puedes usar la que está en la stack.

 symbol address = slide + stack address - load address 
  1. El valor de slide es el valor de vmaddr en LC_SEGMENT cmd (Principalmente esto es 0x1000 ). Ejecute lo siguiente para obtenerlo:

     otool -arch ARCHITECTURE -l "APP_BUNDLE/APP_EXECUTABLE" | grep -B 3 -A 8 -m 2 "__TEXT" 

    Reemplace ARCHITECTURE con la architecture real que muestra el informe de armv7 , por ejemplo, armv7 . Reemplace APP_BUNDLE/APP_EXECUTABLE con la ruta al ejecutable real.

  2. La stack address es el valor hexadecimal del informe de locking.

  3. La load address puede ser la primera dirección que se muestra en la sección Binary Images en la parte delantera de la línea que contiene el ejecutable. (Por lo general, la primera entrada).

Como en el pasado el valor de la slide era igual al valor de la load address esto siempre funcionó. Pero desde que Apple introdujo la distribución aleatoria del espacio de direcciones que comienza con iOS 4.3 (en diferentes variaciones), la dirección de carga de las aplicaciones se aleatoriza por razones de seguridad.

Una alternativa más simple: puede usar el atos -l para que haga los cálculos por usted.

Supongamos que tiene la siguiente línea en su registro de locking que desea simbolizar:

 5 MyApp 0x0044e89a 0x29000 + 4348058 

El primer número hexadecimal es la dirección de la stack, y el segundo número hexadecimal es la dirección de la carga. Puede ignorar el último número. No necesita preocuparse por las direcciones de diapositivas tampoco.

Para simbolizar, haga lo siguiente:

 atos -o MyApp.app/MyApp -arch armv7 -l 0x29000 0x0044e89a 

Si no puede encontrar su archivo MyApp.app/MyApp, cambie el nombre de su archivo ‘.ipa’ a ‘.zip’, descomprímalo y estará en la carpeta Payload.

Y si no está seguro de qué architecture usar (por ejemplo, armv7 o armv7s), vaya a la parte ‘Imágenes binarias’ del archivo de locking y podrá encontrarla allí.

Aclamaciones

Simplemente use dwarfdump:

 dwarfdump --arch armv7 myApp.dSYM --lookup 0xaabbccdd | grep 'Line table' 

No es necesario hacer ningún cálculo en absoluto.

(Desde Obtener símbolo por dirección (simbolizando binario, comstackción de iOS) ).

Para quienes ese cierto tiempo no tiene el valor para Dirección de carga como este:

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

Creé un bash simple para ayudarme a depurar:

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

Simplemente lee la ruta de la aplicación, el nombre de la aplicación, la dirección de la stack 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 comando atos.

Intereting Posts