Se bloquea en el dispositivo mediante la distribución ad-hoc.

De repente, mis distribuciones ad-hoc a través de Testflight y iTunes-sync ya no funcionan. La aplicación distribuida con la configuration ad-hoc nunca comienza completamente en el dispositivo. Se bloquea inmediatamente con un error de segmentación 11.

Lo más extraño con este problema es que una compilation de debugging, en todos los dispositivos mencionados a continuación, funciona a la perfección. Esto me está haciendo creer que hay algo desorderado en mi proyecto.pbxproj . Pero cuando miro en el git-log no veo nada fuera de order, lo único que cambió fue las Arquitecturas ( ARCHS ) y las Arquitecturas Válidas ( VALID_ARCHS ).

¿Estoy en lo cierto al asumir que arruinar las architectures no debería causar un error real en el inicio sino durante el process de compilation?

Algunos antecedentes:
También vale la pena mencionar que tenía instalado Xcode 4.4.1 y 4.5 GM, cuando actualicé el GM a uno de App Store también eliminó mi copy de security de Xcode 4.4.1. Después de ese hipo eliminé de nuevo toda la versión de Xcode, reiniciada e instalada la versión 4.4.1 (esto es para que pueda build para armv6).

Cualquier consejo útil sobre cómo proceder con esta debugging es extremadamente valioso para mí.
Gracias por tu time. <3

Impresión de console y logging de lockings desde el dispositivo:
– https://gist.github.com/3781018
Puedo agregar más loggings si es necesario.

Entorno actual:
– Versión Xcode 4.4.1 (4F1003)
– Mac OS Versión 10.8.2

Configuración del proyecto (pbxproj):
– https://gist.github.com/3780985

Dispositivos probados:
– iPhone 3GS iOS 6
– iPhone 3G iOS 4.2.1
– iPad 2nd Gen iOS 5.1.1
– iPhone 4S iOS 5.1.1
– iPhone 4 iOS 6.0
– iPhone 4S iOS 6.0

Actualizar
Para proceder con la debugging, esto es lo que probé:
1. Omita Testflight y use la antigua forma de publicar un ad-hoc con iTunes. FAIL 2. Reinstallation de los perfiles de suministro FAIL
2. Cree un nuevo usuario en mi máquina y reinstale Xcode. FALLAR
3. Construir desde otra máquina. FALLAR
4. Establezca el nivel de optimization en: -O0 FAIL

Aunque estaba seguro de que no se había cambiado nada del código, no vi otra explicación razonable para esto. Así que empecé a revertir el proyecto en git, mirando con el día en que hice una publicación ad hoc con éxito. ¡Para mi horror, noté que la misma falla de segmentación me seguía a través del tejido del time!
Considerando este hecho, solo quedaba una acción por hacer; una forma muy poderosa de debugging que llamé spray-and-pray. =) En otras palabras, comencé a comentar las secciones del código y ver si eso significaba alguna diferencia y, para mi total sorpresa, realmente lo hizo. Después de unas horas de deshabilitar y habilitar partes de mi aplicación encontré al culpable: nunca se retuvo un NSArray estático. Lo que realmente está desorientando aquí es que la initialization real de la matriz ha estado teniendo el mismo aspecto desde 2010. Entonces, ¿por qué en la tierra esto de repente dio como resultado un error de memory ahora? ¿Y por qué el analizador estático no nos advirtió sobre esto?

Estoy muy cansado en este momento para responder a esas preguntas en este momento, trataré de actualizar la pregunta con más detalles y con suerte una respuesta también mañana.
Una vez más, un gran agradecimiento por cualquiera que haya ayudado hasta ahora. <3

Parece que la causa del problema es el problema de la concurrency:

 Crashed Thread: 1 

En tal caso, puede ser difícil encontrar y resolver la raíz del problema (http://en.wikipedia.org/wiki/Unusual_software_bug#Heisenbug).

Puede ser que esté haciendo algo con un object de varios subprocesss sin una synchronization adecuada; o puede ser object desasignado en un hilo (por ejemplo, hilo 0) e intentar acceder a él desde otro hilo (hilo 1).