Xcode doesn't show the line that causes a crash

拥有回忆 提交于 2019-11-26 14:16:37

You should also ensure that you have breakpoints set for all exceptions. This will cause Xcode to stop at the line where the exception is occurring. Do the following [in Xcode 4]:

  1. In the Project Navigator on the left side of Xcode, click on the breakpoint navigator (almost all the way to the right hand side of the top button bar. The icon looks like a fat right arrow).

  2. At the bottom of the navigator, click the "+" button.

  3. Click "Add Exception Breakpoint".

  4. A new breakpoint will be created. It should be configured as needed but you can tweak its behavior.

  5. Run your project and reproduce the exception.

Also you mentioned that you linked to some 3rd party libraries/frameworks. If the exception is occurring within those frameworks then you are going to have a hard time since the code is compiled and Xcode can't actually show you the line that caused the exception. If this is the case and you are certain you are using the libraries correctly, then you should file a bug report to the maintainers of those libraries.

Mike Gledhill

Simply follow the instructions on this StackOverflow answer:

Enable Zombies

Basically, you just need to "Enable Zombies". Then Xcode should break at whichever line caused the problem.

(It is absolutely shocking that, even in 2017, Xcode still has this turned off by default. Why would you not want to see the line that caused the problem ? And "Enable Zombie Objects" ?! Really ?! Do the Xcode authors really believe that this is a useful name, which would make any kind of sense to new developers ? It is depressing how poor Xcode's rating is, year after year, in the App Store. No one is listening...)

Edit the current scheme and enable NSZombieEnabled, MallocStackLogging, and guard malloc. Then, when your App crashes, type this in the gdb console:

(gdb) info malloc-history 0x543216

Replace 0x543216 with the address of the object that caused the NSInvalidArgumentException and it should give you a much more useful stack trace, showing the lines of your code that are causing the crash.

I have seen this behavior in heavily optimized code; checking,tweaking your target's optimization level and those of 3rd party libs may help. (LLVM 3.0 Optimization level setting)

Are you generating debug symbols?

I wrote code to generate a crash of index out of bound. Following is the exception thrown.

2017-01-07 04:02:57.606 testABC[1694:52966] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSSingleObjectArrayI objectAtIndex:]: index 1 beyond bounds [0 .. 0]'
*** First throw call stack:
(
    0   CoreFoundation                      0x000000010e85cd4b __exceptionPreprocess + 171
    1   libobjc.A.dylib                     0x000000010e2be21e objc_exception_throw + 48
    2   CoreFoundation                      0x000000010e8b5c2f -[__NSSingleObjectArrayI objectAtIndex:] + 111
    3   testABC                             0x000000010dce962d -[ViewController ComplexFunction] + 61
    4   testABC                             0x000000010dce95db -[ViewController thirdFunction] + 43
    5   testABC                             0x000000010dce959b -[ViewController secondFunction] + 43
    6   testABC                             0x000000010dce955b -[ViewController firstFinction] + 43
    7   testABC                             0x000000010dce96c2 -[ViewController viewDidAppear:] + 50
    8   UIKit                               0x000000010ee28a6c -[UIViewController _setViewAppearState:isAnimating:] + 945
    9   UIKit                               0x000000010ee2b7da __64-[UIViewController viewDidMoveToWindow:shouldAppearOrDisappear:]_block_invoke + 42
    10  UIKit                               0x000000010ee29ac4 -[UIViewController _executeAfterAppearanceBlock] + 86
    11  UIKit                               0x000000010ec8d77c _runAfterCACommitDeferredBlocks + 653
    12  UIKit                               0x000000010ec7a273 _cleanUpAfterCAFlushAndRunDeferredBlocks + 566
    13  UIKit                               0x000000010ec9d757 __84-[UIApplication _handleApplicationActivationWithScene:transitionContext:completion:]_block_invoke_2 + 194
    14  CoreFoundation                      0x000000010e8016ac __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
    15  CoreFoundation                      0x000000010e7e66f4 __CFRunLoopDoBlocks + 356
    16  CoreFoundation                      0x000000010e7e5e65 __CFRunLoopRun + 901
    17  CoreFoundation                      0x000000010e7e5884 CFRunLoopRunSpecific + 420
    18  GraphicsServices                    0x00000001126d9a6f GSEventRunModal + 161
    19  UIKit                               0x000000010ec80c68 UIApplicationMain + 159
    20  testABC                             0x000000010dce99df main + 111
    21  libdyld.dylib                       0x000000011174968d start + 1
    22  ???                                 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException

If you read carefully the First Throw call stack

0   CoreFoundation              0x000000010e85cd4b __exceptionPreprocess + 171
1   libobjc.A.dylib             0x000000010e2be21e objc_exception_throw + 48

0 and 1 are the system processes after crash.

 2   CoreFoundation             0x000000010e8b5c2f -[__NSSingleObjectArrayI objectAtIndex:] + 111

2 is the line which caused the exception.

3   testABC                     0x000000010dce962d -[ViewController ComplexFunction] + 61

3 tells you that Class name (ViewController) and function naem (ComplexFunction) in which exception was thrown.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!