CODEWITHSUNDEEP
objective-cxcode4.3
user4951
user4951

Reputation: 33138

EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)

I really can't figure out why I have this bug.

First of all the debugger stop at machine code

enter image description here

The thread also shows nothing. The program stop at no code actually

enter image description here

So it has something to do with _dispatch_worker_thread

What is that?

Any way how I can debug this? Should I just rollback?

Upvotes: 25

Views: 21669

Answers (3)

Zeeshan Tufail
Zeeshan Tufail

Reputation: 516

In my case I was adding an observer for contentSize to a UITextView in viewDidLoad and was never removing it. Fixed it by adding it in viewDidAppear and then removing it in viewWillDisappear. It was so annoying to find out :(

Add observer in viewDidAppear

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

Remove observer in viewWillDisappear

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

Upvotes: 0

kalmiya
kalmiya

Reputation: 3126

This kind of crash will happen when you are running a (vector)extension which is not supported on your CPU.

For example, in xcode 5 under "project-settings / build-settings / Code Generation, set the "Enable Additional Vector extensions" to "AVX2". Build your executable.

Now run it on an:

  • Intel Core i5: it's going to crash (wherever the compiler decided to use avx2) with 'exc_i386_invop subcode=0x0'.
  • Intel Core i7: it will work.

Upvotes: 8

marko
marko

Reputation: 9159

EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP) is the by-product of a __builtin_trap() - which is a GCC and clang intrinsic function. On x86 it we get

    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

The instruction ud2 is the culprit here, and is not handled specially by Xcode.

On ARM we this compiles into trap and results in a trace break-point in XCode. Is this a bug in clang we have here?

Ultimately in the context of the original question, I suspect that the library function that is failing has hit a assertion.

Upvotes: 7

Related Questions