EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)

Question

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

First of all the debugger stop at machine code

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

So it has something to do with _dispatch_worker_thread

What is that?

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

Topi

This usually occurs when an object has already been released before you want to use it. This blog might help but please show some code too. – Premillennial

Have you got a breakpoint set on exceptions? Click the breakpoints tab -> Hit the plus button in bottom left -> Click 'Add Exception Breakpoint' -> Hit done with default settings is normally fine. Then run again – Deluxe

I'll try. FOr some reason it doesn't happen again. Also because I am using ARC I think release and stuff should be taken care off. – Topi

Thanks to @Paul.s. I've been trouble-shooting this for hours. After reading your comment, I DEACTIVATED all Breakpoints. NOW IT WILL RUN. So I must have a breakpoint set in the wrong place. – Splashy

Answer 1

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.

Balladist

Don't have this crash on Intel G620 processor And it crashing every time with AVPlayer class on Intel Core i5. – Disturb

Answer 2

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.

Tillo

As the this exception was the result of an assertion macro, I fixed problem that was generating it in the first place. Luckily, I had the source code for the component in question. Your first port of call should be to get a full backtrace and work down the call-stack. If - as was the case with another poster of a similar problem which I saw - it's in an Apple supplied library, I guess you need to check very thoroughly your use of APIs. – Tillo

I've found a crash in UIApplicationMain which breaks on this instruction ud2 since upgrading to Xcode 12. The project was fine in xcode 11. Any clues as to what would have changed that would cause this to appear? – Ogilvie

the iOS platform SDK? – Tillo

Answer 3

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))];

Cranial