objective c - EXC_BAD_INSTRUCTION(código=EXC_I386_INVOP, subcódigo=0x0)

objective-c xcode4.3

Question

Realmente no puedo entender por qué tengo este error.

En primer lugar, el depurador se detiene en el código de máquina

El hilo tampoco muestra nada. El programa se detiene en ningún código en realidad

Así que tiene algo que ver con _dispatch_worker_thread

¿Que es eso?

¿De alguna manera cómo puedo depurar esto? ¿Debo simplemente retroceder?

Answer 1

En mi caso, estaba agregando un observador para contentSize a un UITextView en viewDidLoad y nunca lo estaba eliminando. Se viewDidAppear agregándolo en viewDidAppear y luego eliminándolo en viewWillDisappear . Fue tan molesto descubrirlo :(

Añadir observador en viewDidAppear

[self.textViewMessage addObserver:self
                           forKeyPath:NSStringFromSelector(@selector(contentSize))
                              options:NSKeyValueObservingOptionNew
                              context:nil];

Eliminar el observador en la viewWillDisappear

[self.textViewMessage removeObserver:self forKeyPath:NSStringFromSelector(@selector(contentSize))];

Answer 2

Este tipo de bloqueo ocurrirá cuando esté ejecutando una extensión (vector) que no es compatible con su CPU.

Por ejemplo, en xcode 5 bajo "Configuración de proyecto / configuración de compilación / Generación de código, configure" Activar extensiones de vectores adicionales "a" AVX2 ". Genere su ejecutable

Ahora ejecútalo en un:

• Intel Core i5: se bloqueará (siempre que el compilador haya decidido usar avx2) con ''exc_i386_invop subcode = 0x0''.
• Intel Core i7: funcionará.

Answer 3

EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP) es el subproducto de __builtin_trap() , que es una función intrínseca GCC y clang. En x86 lo conseguimos

    0x4dfa2:  movl   %esi, (%esp)
    0x4dfa5:  movl   %edx, 4(%esp)
    0x4dfa9:  movl   %eax, 8(%esp)
    0x4dfad:  calll  0x110ffa                  ; symbol stub for: objc_msgSend
    0x4dfb2:  cmpb   $0, %al
    0x4dfb4:  je     38
 -> 0x4dfba:  ud2    
    0x4dfbc:  movl   -32(%ebp), %eax

La instrucción ud2 es la culpable aquí, y no es manejada especialmente por Xcode.

En ARM, esto se compila en trap y da como resultado un punto de interrupción de trace en XCode. ¿Es esto un error en el clang que tenemos aquí?

En última instancia, en el contexto de la pregunta original, sospecho que la función de biblioteca que está fallando ha llegado a una afirmación.