Thanks for the suggestion, Ken. When the breakpoint mystery happened today, "Load symbols lazily" was turned on as you surmised it would be. I just turned it off. I should note that it was turned on because on the prior occasion that I had this problem, messing with this debug option did not seem to help.
Perhaps there's a hole in my knowledge of debugging but I thought breakpoints are set on addresses, not on symbols. Thus, you should be able to set breakpoints and trace execution even within frameworks and other code for which you do not have the sources. Execution should stop at those locations. The only difference between having symbol information and not having it is that you see disassembly as opposed to high level source code. Please correct me if I'm wrong.
There are other interesting things I've seen discussed, for example, a suggestion to change the debug information format to Dwarf with dsym file, which I don't quite understand given that the purpose of a dsym file is to provide symbol information separately from the executable, e.g., to keep around after distributing a stripped Release build.
Any more help in understanding why this problem occurs will be much appreciated.
----- Original Message ----
From: Ken Thomases <email@hidden>
To: Oftenwrong Soong <email@hidden>
Sent: Thu, December 31, 2009 2:27:56 PM
Subject: Re: The case of the broken breakpoints
On Dec 31, 2009, at 3:51 PM, Oftenwrong Soong wrote:
> Under some circumstances (and I cannot yet define exactly what those circumstances are), it appears that Xcode suddenly decides to ignore breakpoints, meaning that gdb does not pause execution on lines where I place a breakpoint.
One thing you don't mention is turning off "Load symbols lazily" in Xcode's preferences (under Debugging). That's been noted as a frequent culprit in situations like this.
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden