Question 130613 in Xcode Question posted in
Whether you're new to Xcode or an experienced developer, our archive has everything you need to know about this integrated development environment (IDE). From basic functionalities to advanced features, our archive covers a wide range of Xcode-related questions and answers. Browse our archive now and find solutions to your Xcode questions, and take your app development skills to the next level

Xcode breakpoints: dotted blue outline

I’m attempting to debug some code in Xcode. When I enable a breakpoint in the Xcode file’s gutter, it shows up as a dotted line outline of the normal breakpoint:

Xcode breakpoint dotted line

I can’t enable the breakpoint; it’s either disabled or dotted.

What is the meaning of a dashed line Xcode breakpoint? Why can’t I enable it?

Tags:

5

Answers


  1. 0

    It means the breakpoint is on a line of code that will never be executed.

    For example:

    enter image description here

    Login or Signup to reply.
  2. 0

    Try checking that your preprocessor macro is set to DEBUG=1.

    Project > Build Settings > Preprocessor Macros

    Project > Build Settings > Preprocessor Macros

    Login or Signup to reply.
  3. 0

    If you hover over such a disabled breakpoint, it will display:

    Xcode won’t pause at this breakpoint because it has not been resolved.
    Resolving it requires that:

    • The line at the breakpoint is compiled.
    • The compiler generates debug information that is not stripped out (check the Build Settings).
    • The library for the breakpoint is loaded.
    Login or Signup to reply.
  4. 0

    I had the same problem, and my evidence points to a bug in Xcode 13 that Apple might be in denial of.

    I recently upgraded to Xcode 13.4.1 + Monterey 12.6.3, which resulted in an existing macOS app that I could no longer debug. None of the posted fixes made a difference. Unlike all the other sufferers of this issue on the internet, I had the interesting scenario where some breakpoints do work (ones which are in the main code) and others do not work (ones which are in a particular sub module).

    I can tell you what did NOT work to fix this issue for me: I tried re-cloning the entire repo in a different location and building from scratch, tried deleting all derived data, deleting all build data, rebooting, turning SIP off. The -g -O0 flags to enable debugging are on for the sub module files being compiled where the breakpoints won’t enable. Since I am on an intel machine, I have also tried rebuilding only for intel, rather than a dual binary for intel + ARM64. Due to framework requirements, I must still use the legacy build system, which is removed in Xcode 14, so there is a chance that this issue might relate to that.

    The really absurd thing is that I can set a break point in code where breakpoints do work, and then step down into code where the breakpoints do not work, and continue stepping through the lines of code where the breakpoints are outlined. This proves 100% that the line of code at the breakpoint which is outlined IS compiled, and it IS executable, and it DOES have debug information, and the library IS loaded, because damn it I have just stepped through it with the debugger. I just cannot get the Xcode to stop at the breakpoint there, because Xcode 13 thinks it knows better and decides to outline the break point as unreachable code. I hope Apple is taking note, because this proves this is an Xcode 13 bug.

    I created a test file with a break point in it which printed hello world to the console, and placed it in the sub module folder. Breakpoint not usable.
    I moved the file out of the sub-module folder but continued to compile it from the submodule’s unity build file. Breakpoint now usable. Indisputable evidence that the LOCATION of the file was the issue, not how it was being compiled.

    Solution: After all the failures above, the thing that actually fixed the problem for me was to rename the folder in which the sub-module code was sitting, and suddenly the breakpoints in that submodule all worked.

    Login or Signup to reply.
  5. 0

    I don’t know why the GCC_GENERATE_DEBUGGING_SYMBOLS value changed to "NO" so it wasn’t working. After changing to "YES", the above phenomenon disappeared.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search