Xcode stops at breakpoints and seems to hang

I am trying to debug a small prototype for an iPhone App (iOS Simulator 4.1), compiled as Debug, with all the configuration apparently ok.

The application makes use of Cocos2d graphic engine and GDataXMLNode library (for XML reading). There isn’t much stuff going on. But on certain method, if I set a breakpoint, gdb simply “stops”.

Here’s the status line of the debugger after it hits he breakpoint:

And here’s the code that has the breakpoint(sshot):

note: the breakpoint could be anywhere in that function and it’s the same.

And this is the calling code (from another object)

self.map = [SimulationLoader loadMap];

None of the Editor buttons work when a breakpoint is set inside the “loadMap" (step into, step out, next, continue execution, etc.). I can stop and/or restart the debugging and it works (but goes back to the beginning). The gdb prompt, will let me write, but nothing happens. I cannot view object values or anything debugging related. I cannot resume execution, it won’t do anything.

The strange thing is that, if I put a breakpoint before or after that line (the loadMap), it all works, and I can step out or in, debug it and do all I wan开发者_JAVA技巧t to do.

What am I missing?

A couple of seconds after the “failing” breakpoint is hit (and it “hangs”) the stack window clears. I believe all this happens because the gdb has stopped, but the question is, why does it stop there? What are the restrictions for this?

I’m compiling with LLVM GCC 4.2 for what is worth (but could probably change to other if that’s the problem, haven’t tried that because I don’t know much about the differences).

---

Is there something (maybe in your Map class?) that requires timing? For instance, a double-tap that's being interrupted by the breakpoint's being triggered at that spot?

(i.e., no breakpoint => double-tap registered, Breakpoint => second tap comes after breakpoint hits, so only a single-tap is registered.)

I don't see anything like this in your code specifically, but that's the kind of thing that could show mysteriously different behavior between breakpoints on/off.