The application stops working because the code you are running has thrown a Mach exception without exception. Mach exceptions are the BSD Signals equivalent for the Mach kernel - which is the lowest level of the macOS operating system.
In this case, Mach's specific exception is EXC_BREAKPOINT . EXC_BREAKPOINT is a common source of confusion ... Because it has the word “breakpoint” in the name, people think this is the breakpoint of the debugger. This is not entirely wrong, but the exception is used more widely than this.
EXC_BREAKPOINT is actually the exception that the lower levels of Mach report when it executes a specific instruction (trap command). This trap command is used by lldb to implement breakpoints, but it is also used as an alternative to assert on various bits of system software. For example, swift uses this error if you are accessing the end of an array. This is a way to stop your program right at the point of error. If you work outside the debugger, it will crash. But if you are working in a debugger, then control will be returned to the debugger with this EXC_BREAKPOINT stop error.
To avoid confusion, lldb will never show you EXC_BREAKPOINT as a stop cause if the trap was such that lldb is inserted into the program you are debugging to implement the debugger breakpoint. He will always say breakpoint nn .
So, if you see that the thread is stopped with EXC_BREAKPOINT as the reason for stopping, it means that you made some fatal error, usually in some kind of system library used by your program. At this point you will see which component raises this error.
In any case, having hit this error, you tried to find out the value class in the eax register by calling the class method on it by running po [$eax class] . Calling this method (which will cause code to run in the program you are debugging) will crash. This is what the error message told you about.
This is almost certainly because $eax does not point to a valid ObjC object, so you are just calling a method with some random value and this crashes.
Note that if you are debugging a 64-bit program, then $ eax is actually the lower 32 bits of the real argument passing the register - $ rax. The lower 32 bits of a 64-bit pointer are unlikely to be the actual value of the pointer, so it’s not at all surprising that calling the class on it failed.
If you tried to call the class on the first argument passed (self in ObjC methods) on 64-bit Intel, you really wanted to:
(lldb) po [$rax class]
Note that this also hardly worked, since $rax holds self at the beginning of the function. Then it is used as a scratch register. So if you enter this function in any way (that the fact that your code fatally failed some test seems likely) $ rax is unlikely to hold self .
Note that if this is a 32-bit program, then $eax is not actually used to pass arguments — Intel's 32-bit code passes arguments on the stack, not in registers.
In any case, the first thing to do to find out what went wrong is to print the return line when you get this exception and see what code was running when this error occurred.