No Break Point Functionality?


#1

Hello

 

OSX  10.10, Reaper 4.76, Xcode 6.2

 

Breakpoints don't work. Never have - I'm working on a very complex project and I've tried goofing around with some debug settings (to be honest, I have no idea what I'm doing with the build settings, so it was all guesswork and nothing fixed it :( )

Does anyone else here have any idea how to enable breakpoints in my code, so that I can break for real? Making annoying alerts is really a P.I.T.A and I'm working on something where if I did have break points as a tool, I could do this in 5 minutes - however, it will take me hours without breakpoints to find whats going on where.

 

If you can help me, please be specific - I don't want to have to double-ask you again 'what do you mean exactly when you say x'?

Thanks a million!


#2

Are you trying add a break point in a source file that is not directly being compiled? by that I mean does another source file include the source file that you are trying to break in to?

If you are trying to break into something inside of JUCE then the answer will very likely be yes. JUCE uses unity build methods (that is cpp files that include other cpp files. See something like: JUCE/modules/juce_box2d/juce_box2d.cpp as a simple example).

Rather than me trying to explain why this is a problem and how to work around it, I'll just quote from the LLDB FAQ (http://lldb.llvm.org/troubleshooting.html):

When setting breakpoints in implementation source files (.c, cpp, cxx, .m, .mm, etc), LLDB by default will only search for compile units whose filename matches. If your code does tricky things like using #include to include source files:

% cat foo.c #include "bar.c" #include "baz.c" ...

This will cause breakpoints in "bar.c" to be inlined into the compile unit for "foo.c". If your code does this, or if your build system combines multiple files in some way such that breakpoints from one implementation file will be compiled into another implementation file, you will need to tell LLDB to always search for inlined breakpoint locations by adding the following line to your~/.lldbinit file:

% echo "settings set target.inline-breakpoint-strategy always" >> ~/.lldbinit

This tells LLDB to always look in all compile units and search for breakpoint locations by file and line even if the implementation file doesn't match. Setting breakpoints in header files always searches all compile units because inline functions are commonly defined in header files and often cause multiple breakpoints to have source line information that matches many header file paths.

If you set a file and line breakpoint using a full path to the source file, like Xcode does when setting a breakpoint in its GUI on Mac OS X when you click in the gutter of the source view, this path must match the full paths in the debug information. If the paths mismatch, possibly due to passing in a resolved source file path that doesn't match an unresolved path in the debug information, this can cause breakpoints to not be resolved. Try setting breakpoints using the file basename only.

So in short, to the fix the issue run the following from terminal:

echo "settings set target.inline-breakpoint-strategy always" >> ~/.lldbinit

I'm sure I have found the need for a restart following this in thes past, however that may or may not actually be nessercary.

If that doesn't fix your issue then let me know, there are other work arounds when experiencing issues with break points.


#3

You could also make sure you step into JUCE code manually once and after that it seems that XCode does pick up breapoints after that. ALthough not in all files, it's annoying. I'll give Anthony suggestion a go as well, i hope this works.


#4

What are you hosting your plugin in? If you use JUCE's audio plugin host, you can compile a debug build (so it has all the symbols) and you should be able to debug from that.