versiones seguridad restaurar que puedo hacer guarda copia caracteristicas apple objective-c xcode ios5 xcodebuild lldb

objective c - seguridad - Aplicación de iOS que se bloquea antes de ingresar a main() con Xcode 4.2 e iOS 5



que guarda la copia de seguridad de itunes (11)

Fondo

Después de actualizar xcode4.1 / ios4 a xcode4.2 / ios5 , estoy experimentando bloqueos mientras la aplicación se está cargando e incluso antes de que entre en main() .

He establecido un punto de interrupción en main() pero nunca se alcanza.

  • Compilar el proyecto en Xcode 4.1 con un Base SDK de 4.3 funciona bien en iOS 4.xy iOS 5.
  • Compilar el mismo proyecto en Xcode 4.2 con un Base SDK de 5.0 funciona bien en 4.x pero se bloquea en iOS 5, tanto en el simulador como en un dispositivo.

Simulator Crash

Bloqueos con EXC_BAD_ACCESS

Lista de llamadas, todas las llamadas al sistema, ni siquiera main() aún no se ha llamado.

Mi mejor suposición es que es un problema cargar una biblioteca, ¡pero tengo una idea clara de cómo rastrearla!

Intenta una resolución

  1. Activado Zombies
  2. Activado todo el registro
  3. Se agregaron diferentes versiones de las bibliotecas del sistema (libz.1.2.5.dylib y libz.dylib)
  4. Limpiar el proyecto
  5. Se eliminó la aplicación del simulador
  6. Eliminar la carpeta de Derived Data

Puede aplicar el indicador del enlazador de forma condicional a los SDK de iOS pero no al simulador de iPhone en XCode 4.

Seleccione Otros indicadores de enlazador, haga clic en Agregar configuración de compilación, elija Agregar configuración condicional y aplique -weak_library /usr/lib/libSystem.B.dylib solo para iOS SDK.

Esto permite que las construcciones del simulador sigan funcionando.


Parece que recuerdo haber tenido un error similar antes de llamar a main () y lo rastreé hasta una discrepancia entre IBOutlets declarados en el delegado de la aplicación vs en mis extremos. Revisa y revisa tus puntos de venta para ver si hay algún error de configuración.

-mz


Verifica tus banderas enlazadoras. Algunas bibliotecas que podrías haber estado usando requieren una bandera como esta:

-weak_library /usr/lib/libSystem.B.dylib

La vinculación débil permitió construir contra iOS 4.x con un objetivo de despliegue 3.x. Por alguna razón, ahora está completamente roto en el simulador.


Xcode 4.2 todavía tiene algunas asperezas de mi uso. Una desinstalación y reinstalación completa resolvió un problema que tenía (estaba bloqueado en "Adjuntar" y ninguna de las soluciones del subproceso SO "oficial" me ayudó). Puede ser un poco extremo sin embargo.

Seleccione el proyecto de nivel superior en File Navigator y vaya a la pestaña Build Fhases. Expanda la sección "Enlace binario con marcos": ¿hay marcos que no estén provistos por Apple? ¿Son opcionales o obligatorios? ¿Y alguno de sus códigos requiere marcos adicionales?

Para ayudar más, ¿podría publicar todos los mensajes de registro que están siendo ocultados por la ventana emergente de la pila de llamadas?


Intenté todo en rjstelling y las publicaciones de MarkGranoff fueron en vano. Ahora puedo reproducir de forma reproducible que no ocurra desactivando Guard Malloc en mi esquema de depuración. Proteja a Malloc - crash, off - no crash. Nunca tuve el problema en el dispositivo solo el simulador. Apliqué las correcciones en la publicación anterior, así que no sé si esto hubiera solucionado el problema sin esos cambios o no. Espero que esto ayude a alguien más.


Estaba jugando con los diagnósticos del esquema, y ​​obtuve este mismo comportamiento al configurar accidentalmente "Habilitar Guard Malloc". Me había dirigido a 4.3 y me estaba ejecutando bajo ARC en el simulador 5.0. La aplicación funcionaría bien cuando se lance desde el simulador, pero no desde XCode. Vaya a Producto-> Editar esquema ..., seleccione el ítem "Ejecutar" en la tabla a la izquierda, y luego la pestaña "Diagnósticos" a la derecha. Desmarque "Habilitar Guard Malloc".


Tenía exactamente el mismo diagnóstico, pero la solución era completamente diferente.

Sin embargo, la solución que se describe en las respuestas aquí no funcionó para mí, porque no encontré problemas relacionados con "débiles" en mi proyecto.pbxproj

Sin embargo, descubrí que la causa de mi problema era un punto muerto en un método de +(void)initialize llamado desde el hilo principal. En este método, estaba llamando a dispatch_sync(dispatch_get_main_queue(), ^{[some block code]}) . Cambiar esto a un dispatch_async (observe la "a") resolvió mi problema.

La forma en que descubrí el problema fue accidental. Si bien nada parecía suceder, el navegador "hilo" de Xcode me decía que la aplicación en sí no se había bloqueado. Y accidentalmente hice clic en "pausa" en el depurador. Y de repente se detuvo exactamente donde estaba el punto muerto. Lo cual después de algunos pensamientos es lógicamente obvio.


Una aplicación que se cuelga antes de ingresar a main.m puede suceder cuando un marco vinculado no se copia, por ejemplo porque el proyecto usa Cartago y falta la fase de compilación Run Script /usr/local/bin/carthage copy-frameworks .


¿Cuál es su objetivo de despliegue?

Mi objetivo de implementación era iOS4.0. Lo cambié a iOS4.3 y el problema se resuelve! (Construyendo contra iOS5 GM SDK, por supuesto.) Mi aplicación ahora se ejecuta en el simulador iOS5.

Obtuve esta idea a partir de una respuesta en otro hilo SO que decía que ARC es compatible con iOS4.3 y superior. Mi aplicación no usa ARC, ni ninguna de sus bibliotecas dependientes, por lo que yo sé. La respuesta también decía algo acerca de la reducción a cero de referencia débil, que parecía ... tal vez relevante ya que mucha gente ha tenido éxito en la eliminación de directivas de vinculador específicas relativas a las referencias débiles a libSystem.B.dylib.

Me molesta un poco que tenga que mover mi objetivo de implementación base más allá de 4.0 porque me parece que estoy eliminando a muchos usuarios potenciales. A pesar de la esperanza de Apple de que todos siempre actualicen sus dispositivos, muchas personas no lo hacen. Oh bien.

EDITAR

Vale la pena mencionar que este proyecto se realizó originalmente bajo Xcode3, por lo que es probable que exista algún error en el proyecto en sí que sea innecesario y cause este problema. ¡Pero estaré condenado si puedo encontrarlo!

EDIT 2

Bueno, bueno, bueno ... tras otra inspección ... encontré 2 referencias errantes a libSystem.B.dylib en mi archivo project.pbxproj que no eran visibles a través de la configuración de compilación de Xcode, pero que tuve que eliminar a mano con una ¡editor de texto!

Una vez hecho esto, restablecí la versión de implementación básica a 4.0, creada para el simulador iOS5, y la aplicación se ejecutó sin problemas.

Asombroso.

La lección: Nunca subestimes las posibilidades de que haya basura en tu archivo de proyecto.

EDIT 3

Eliminando las 3 apariciones de estas líneas en el archivo project.pbxproj dentro del paquete del proyecto Xcode (haga clic con el botón derecho y muestre el contenido del paquete).


Guard malloc era el problema para mí también. Probablemente porque estoy usando libxml2.2.7.3.dylib.

Esta pregunta describe el mismo choque, pero tuvo la suerte de estar activando malloc, por lo que fue obvio qué causó el bloqueo. Acabo de recibir el bloqueo después de actualizar Xcode a 4.2.

Me gustaría incluir el seguimiento de pila para que sea Googleable. Tuve problemas para encontrar esta página.

#0 0x00000000 in <????> () #1 0x99924ef3 in mig_get_reply_port () #2 0x9991e70c in mach_ports_lookup () #3 0x0141c124 in _xpc_domain_init_local () #4 0x01419eb1 in _libxpc_initializer () #5 0x8fe2a15b in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE () #6 0x8fe29cc0 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE () #7 0x8fe27220 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #8 0x8fe271b6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #9 0x8fe271b6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #10 0x8fe271b6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #11 0x8fe271b6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #12 0x8fe281c0 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE () #13 0x8fe1c626 in __dyld__ZN4dyld24initializeMainExecutableEv () #14 0x8fe20ef2 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ () #15 0x8fe1a2ef in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_ () #16 0x8fe1a063 in __dyld__dyld_start ()


Tuve un problema similar con la prueba de unidad lógica (ejecutando un objetivo separado sin dependencia de la aplicación principal en el simulador de iOS), en mi situación el problema estaba en lldb, aquí hay más detalles:
La unidad lógica prueba bloqueo