cocoa - ¿Las excepciones "EXC_BREAKPOINT(SIGTRAP)" son causadas por la depuración de puntos de interrupción?
macos exception (4)
¿Las excepciones "EXC_BREAKPOINT (SIGTRAP)" son causadas por la depuración de puntos de interrupción?
No. De otra manera, en realidad: un SIGTRAP (trace trap) hará que el depurador rompa (interrumpa) su programa, de la misma manera que lo haría un punto de interrupción real. Pero eso es porque el depurador siempre se rompe en un bloqueo, y un SIGTRAP (como varias otras signals ) es un tipo de bloqueo.
Los SIGTRAP generalmente son causados por NSExceptions que se lanzan, pero no siempre, incluso es posible raise uno directamente.
Ahora me he dado cuenta de que olvidé eliminar algunos puntos de interrupción de la depuración, incluidos _NSLockError, [NSException raise] y objc_exception_throw.
Esos no son puntos de ruptura. Dos de ellos son funciones y -[NSException raise] es un método.
¿Quisiste decir que estableces puntos de interrupción en esas funciones y ese método?
Supongo que el uso de la configuración "Release" evita la configuración de cualquier punto de interrupción--
No.
Las configuraciones son configuraciones de compilación . Afectan la forma en que Xcode construye sus aplicaciones.
Los puntos de interrupción no son parte de la construcción; los pones en el depurador Solo existen, solo reciben un golpe, y solo detienen tu programa cuando ejecutas tu programa bajo el depurador.
Como no forman parte de la compilación, no es posible pasar sus puntos de interrupción a un usuario simplemente proporcionándoles el paquete de la aplicación.
No estoy seguro exactamente cómo funcionan los puntos de interrupción ...
Cuando su programa llega al punto de interrupción, el depurador interrumpe (interrumpe) su programa, con lo que puede examinar el estado del programa y avanzar cuidadosamente para ver cómo funciona el programa.
Como es el depurador el que detiene su programa, los puntos de interrupción no tienen efecto cuando no está ejecutando su programa bajo el depurador.
... o si el programa necesita ejecutarse desde gdb para que los puntos de interrupción tengan algún efecto.
Lo hace. Los puntos de interrupción del depurador solo funcionan dentro del depurador.
Mis preguntas son: ¿podría haber dejado los puntos de ruptura establecidos ser la causa de los bloqueos observados por el usuario?
No.
En primer lugar, como se señaló, incluso si estos puntos de interrupción de alguna manera se transfieren al sistema del usuario, los puntos de interrupción solo son efectivos en el depurador. El depurador no puede detenerse en un punto de interrupción si su programa no se ejecuta bajo el depurador. Es casi seguro que el usuario no está ejecutando su aplicación bajo el depurador, especialmente desde que obtuvieron un registro de bloqueo.
Incluso si ejecutaron su aplicación bajo el depurador con todos estos puntos de interrupción establecidos, un punto de interrupción solo se activa cuando su programa llega a ese punto, por lo que uno de estos puntos de interrupción solo podría _NSLockError si usted o Cocoa llamaron _NSLockError , -[NSException raise] , o objc_exception_throw . Llegar a ese punto no sería la causa del problema, sería un síntoma del problema.
Y si se bloqueó como resultado de uno de los llamados, su registro de bloqueo tendría al menos uno de ellos nombrado en él. No es así
Por lo tanto, esto no estaba relacionado con sus puntos de interrupción (máquina diferente, depurador no involucrado), y no era una excepción de Cocoa, como mencioné, las excepciones de Cacao son una de las causas de los SIGTRAP, pero no son las únicas. Encontraste uno diferente.
Si no, ¿alguien más ha tenido problemas similares con [NSFont fontWithName: size:]?
No hay manera de que sepamos si los problemas que hemos tenido son similares porque cortó el registro de bloqueo. No sabemos nada sobre en qué contexto ocurrió el accidente.
Lo único que es bueno cortar es la sección de "Imágenes binarias", ya que no tenemos sus paquetes dSYM, lo que significa que no podemos usar esa sección para simbolizar el registro de bloqueo.
Tú, por otro lado, puedes. Escribí una aplicación para este propósito; alimentar el registro de fallas, y debe detectar el paquete dSYM automáticamente (mantendrá el paquete dSYM para cada compilación de versión distribuida, ¿no?) y restaurar los nombres de su función y método en el seguimiento de la pila donde aparezcan sus funciones y métodos.
Para obtener más información, consulte la Guía de depuración de Xcode .
Tengo una aplicación multiproceso que es muy estable en todas mis máquinas de prueba y parece ser estable para casi todos mis usuarios (en base a ninguna queja de fallas). Sin embargo, la aplicación falla frecuentemente para un usuario, quien tuvo la amabilidad de enviar informes de fallas. Todos los informes de fallos (~ 10 informes consecutivos) se ven esencialmente idénticos:
Date/Time: 2010-04-06 11:44:56.106 -0700
OS Version: Mac OS X 10.6.3 (10D573)
Report Version: 6
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x90ab98d4 __CFBasicHashRehash + 3348
1 com.apple.CoreFoundation 0x90adf610 CFBasicHashRemoveValue + 1264
2 com.apple.CoreText 0x94e0069c TCFMutableSet::Intersect(__CFSet const*) const + 126
3 com.apple.CoreText 0x94dfe465 TDescriptorSource::CopyMandatoryMatchableRequest(__CFDictionary const*, __CFSet const*) + 115
4 com.apple.CoreText 0x94dfdda6 TDescriptorSource::CopyDescriptorsForRequest(__CFDictionary const*, __CFSet const*, long (*)(void const*, void const*, void*), void*, unsigned long) const + 40
5 com.apple.CoreText 0x94e00377 TDescriptor::CreateMatchingDescriptors(__CFSet const*, unsigned long) const + 135
6 com.apple.AppKit 0x961f5952 __NSFontFactoryWithName + 904
7 com.apple.AppKit 0x961f54f0 +[NSFont fontWithName:size:] + 39
(.... más texto a continuación)
Primero, pasé mucho tiempo investigando [NSFont fontWithName: size:]. Pensé que tal vez las fuentes del usuario estaban arruinadas de alguna manera, por lo que [NSFont fontWithName: size:] solicitaba algo inexistente y falla por ese motivo. Agregué un montón de código usando [[NSFontManager sharedFontManager] availableFontNamesWithTraits: NSItalicFontMask] para verificar la disponibilidad de la fuente por adelantado. Lamentablemente, estos cambios no solucionaron el problema.
Ahora me he dado cuenta de que olvidé eliminar algunos puntos de interrupción de la depuración, incluidos _NSLockError, [NSException raise] y objc_exception_throw. Sin embargo, la aplicación se creó definitivamente utilizando "Release" como la configuración de compilación activa. Supongo que el uso de la configuración de "Liberar" impide el establecimiento de puntos de interrupción, pero tampoco estoy seguro de cómo funcionan los puntos de interrupción ni si el programa debe ejecutarse desde gdb para que los puntos de interrupción tengan algún efecto.
Mis preguntas son: ¿podría haber dejado los puntos de ruptura establecidos ser la causa de los bloqueos observados por el usuario? Si es así, ¿por qué los puntos de interrupción causan un problema solo para este usuario? Si no, ¿alguien más ha tenido problemas similares con [NSFont fontWithName: size:]?
Probablemente solo trate de eliminar los puntos de interrupción y devolverlos al usuario, pero no estoy seguro de cuánto dinero me queda con ese usuario. Y me gustaría entender más en general si dejar los puntos de interrupción establecidos podría causar un problema (cuando la aplicación se construye utilizando la configuración de "Liberar").
Es muy probable que este usuario tenga una fuente corrupta instalada. El seguimiento de la pila definitivamente respalda esa hipótesis, al igual que el hecho de que solo afecta a un usuario.
No hay mucho que pueda hacer en ese caso excepto que el usuario elimine la fuente ofensiva, ya que los bloqueos que se producen se producen en el fondo del código de Apple.
Intente hacer que el usuario ejecute una validación de fuente en el Libro de fuentes. Para ello, inicie el Libro de fuentes, haga clic en Todas las fuentes en la lista fuente y luego seleccione todas las fuentes enumeradas. A continuación, puede seleccionar Validar fuentes en el menú Archivo .
Los puntos de interrupción no están escritos en el binario. Las probabilidades son buenas de que esta persona tenga una instalación de sistema operativo que no funciona. Verifique los registros de la consola para ver si hay mensajes dyld.
Yo tenía el mismo error. Por una razón inexplicable, el punto de interrupción fue el responsable de lanzar la excepción EXC_BREAKPOINT . La solución fue eliminar el punto de interrupción, y luego el código funciona.
EXC_BREAKPOINT es un tipo de excepción que usan los depuradores. Cuando establece un punto de interrupción en su código, el compilador inserta una excepción de este tipo en el código ejecutable. Cuando la ejecución llega a ese punto, se lanza la excepción y el depurador lo atrapa. Luego, el depurador muestra su código en la línea "breakpointed". Así es como funcionan los depuradores. Pero en este caso, el depurador no maneja la excepción correctamente y se presenta como un error de excepción regular.
He encontrado este error dos veces en mi vida:
- uno usando Xcode hace aproximadamente un año.
- el otro usa Visual C ++ hace unos 15 años.