Xcode debugger stops when NOT going through break

I have some c++ code, very simple:

195 MyModelItem *parentItem = thisItem->parent();
196 if(parentItem == NULL)
197 {
198 std::cout << "parentItem is NULL\n";
199 bool parentIsNull = true;
200 if(parentIsNull)
201 return QModelIndex();
202 return QModelIndex();
203 }
204 else if((unsigned int)parentItem == 0x4d0000)
205 {
206 std::cout << "parentItem is 0x4d0000\n";
207 return QModelIndex();
208 }
209 else if (parentItem == m_root)
210 return QModelIndex();
211
212 return createIndex(parentItem->row(), 0, parentItem);
213 }

I put a breakpoint on line 200 -- the one that is inside the if-clause and says:
bool parentIsNull = true;
There is a cout right above that line. So the breakpoint should not be triggered except when parentItem is NULL, and the debugger console should have the "parentItem is NULL" message logged to it.

But, in fact, the breakpoint gets triggered every single solitary time the function gets called. According to the GDB status reported on the debugger console, it claims that it has stopped at "Breakpoint 1" and that it is "Line 200". Line 200 is indeed the line that I put the breakpoint on, but the little red arrow is not on Line 200, it's on Line 204. If I single-step after the breakpoint stops, it goes to line 209, then the red arrow jumps to the "return" statement which is at the end of the previous function in the file, and then finally to line 213 -- which is one line after the actual return statement.

So does anyone know any way to get the debugger to behave? To only stop when the breakpoint in question actually gets triggered? It would be nice if the single-step behavior followed what code is supposed to be executing, but I would settle for not stopping at "phantom" triggers.

macbook pro, Mac OS X (10.5.4)

Posted on Sep 8, 2009 2:29 PM

Reply
3 replies

Sep 9, 2009 1:50 AM in response to cathy fasano

I would settle for not stopping at "phantom" triggers.


Do you know how to go in and check/clear those phantoms?

Try this... Open the debugger console, and when the debugger stops on an otherwise 'invisible' breakpoint, type "clear" after the "(gdb)" prompt and hit enter/return.

That should remove the phantom - repeat as required & if you like, you can review the status of all breakpoints by typing "info breakpoints" at the "(gdb)" prompt. Note, that the debugger apparently needs to be stopped for these console commands to execute properly. Perhaps you know how to use the 'Run/Show/Breakpoints' menu/window as well.

If you haven't made the leap yet, consider moving to Xcode 3.2 which provides improved breakpoint handling along w/enhanced error pinpointing & feedback.

Sep 9, 2009 7:35 AM in response to K T

When I type "clear" at the gdb prompt, I get a "No source file specified" error...

I'm not sure that I am being clear on my problem here. I have a breakpoint at line 200. Line 200 is inside the if-clause
if(parentItem==NULL) { ... }

I want the program to stop at line 200, but only if parentItem==NULL. In my previous experience with every debugger I've used (including many years using gdb) if you set a break on a line of code that only executes if some condition is true, then the breakpoint only gets triggered, and the program only stops, if the condition is true and the line of code that the breakpoint is on executes. What I am seeing is that Xcode wants to stop at the breakpoint if the line is executed, but also stop at the next line which is executed if that line is not executed. I can set the breakpoint to a log-and-continue state, but then it logs and continues when I want it to stop. I tried setting the condition of parentItem==NULL in the edit breakpoint dialog, but then it says "Error in testing breakpoint condition:"

When I've seen this behavior before it has been related to not getting optimization turned off. (The optimization makes the whole swath of code disappear, and so the debugger just kinds improvises on the line numbers and stops whenever you are in the vicinity.) But I have checked the project settings over and over, and it's set debug, and optimization is set to NONE, and I just can't see anything else to turn on/off to get breakpoints to work.

Sep 9, 2009 10:29 AM in response to cathy fasano

I'm not sure that I am being clear on my problem here.


You're clear - I get/got your specifics.

A similarly biased response, however would only occur if your issue was equally solvable. It is obviously not, or you would already have been able to shine a light on it and easily weed it out.

Xcode breakpoint 'phantoms' typically occur when trigger code is deleted and the bp is still set. The line number associated with the bp is gone, out of sequence and/or unreachable during a stop. This lack of reliable data is then unreliably interpreted during any attempt by Xcode to help out.

At best, the wrong line is referenced, leaving the user to flounder unless they ignore such pointers and treat the seemingly non-existant bp like any other - this should present an opportunity to manually prune, but only if it is addressed directly. At worst, well....here we are.

You may want to consider moving to a backup of said project where you can remove all breakpoints with all code intact and then start cutting lines of code instead of wasting more time letting this one get the best of you.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Xcode debugger stops when NOT going through break

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.