DBG() and breakpoints in XCode

General JUCE discussion
1

This might be a weird question, but whatever lol

Does anyone else experience XCode always breaking on String::~String() whenever you set a breakpoint near a DBG() statement? Without fail, on XCode on both my iMac (10.9.5) and my laptop (10.11) the DBG() statements always cause XCode to break on the StringHolder::release(text); line. It’s the strangest behavior, and has been that way as long as I have been using juce (about 2.5 years).

It’s not horrible, just annoying. every time i am stepping through my code, I’ll step over a DBG() statement and find the debugger automatically pausing on String::~String()

Anyone else experience this?

Same goes for the occasional Debugger pauses inside or if I happen to use std::vector<> operator[]
…maybe it’s the _LIBCPP_ASSERT()? it’s just weird…

2

Yes, it’s annoying…but I believe it’s because the macro has multiple lines

 DBG (dbgtext)
 {
 juce::String tempDbgBuf; 

 tempDbgBuf << dbgtext; 

 juce::Logger::outputDebugString (tempDbgBuf);
 }

and when we step over it’s stepping into the tempDbgBuf destructor.

The odd thing…

{
int g = 9;
int f = 10;

// String szTest ("Hey");

DBG ("Test: " + String (g) + String (f));  // Breakpoint on this line

++g;
}

You have to F6 (Step Over) twice to perform the step and with the szTest String commented out you don’t step into the String destructor… but if you simple uncomment that line and step over again… Xcode will step into the Destructor.

Rail

1 Like
3

but why would we be stepping into the String destructor in the first place? There’s no breakpoint on it telling the debugger to stop there…

4

It has to be an Xcode bug in the debugger :smile:

Rail

1 Like
5

this seems to have stopped happening with the latest XCode update? I haven’t noticed it in a while anyway…

6

I do a lot of debugging and can’t say I’ve ever noticed a problem like that.

My main beef with Xcode is that it regularly just gets all the line numbers out by 1, so that errors and debug positions are shown wrongly, but a workaround for that is just to close and re-open the source file, which seems to make it re-scan it and recover.

7

Yes I’m seeing this as well. I think it may be an lldb/clang problem as I also see this with Android Studio.