Re: The case of the broken breakpoints
Re: The case of the broken breakpoints
- Subject: Re: The case of the broken breakpoints
- From: "Paul Sanders" <email@hidden>
- Date: Sun, 3 Jan 2010 00:35:13 -0000
Try just deleting the files in the <project>.xcodeproj folder
beginning with your username. This is where breakpoints and
suchlike are stored between sessions. I guess you could also
copy the project folder before you start. Then you have a clean
copy to go back to.
Did 'sha app all' not work then? It is a magic bullet for me,
although I don't seem to have this problem with breakpoints
placed in the app itself (only in dylibs). And I have found an
excellent way to confuse Xcode: #include the same source file
(as opposed to header file) in more than one place. Hardly
surprising really...
Paul Sanders.
----- Original Message -----
From: "Oftenwrong Soong" <email@hidden>
To: <email@hidden>
Cc: <email@hidden>
Sent: Sunday, January 03, 2010 12:21 AM
Subject: Re: The case of the broken breakpoints
Hi all,
First, many thanks to Jason Molenda for the very helpful
explanation of how Xcode interfaces with gdb. That filled in
quite a few holes in my knowledge of how debugging works.
Somehow, I must have managed to confuse Xcode in the manner
Jason described:
On Thu, December 31, 2009 4:34:01 PM, Jason Molenda
<email@hidden> wrote:
> The optimization falls down in two main cases: Symbolic
> (function name)
> breakpoints and when the Xcode session doesn't know what
> executable a
> source file maps to. With symbolic breakpoints, Xcode doesn't
> know what
> dylib this might be in - if you do Run > Show > Breakpoints
> you'll see a
> "Location" entry where you can add a dylib/framework/etc name
> but Xcode
> doesn't know how to fill that in itself. In the latter case,
> a common issue is
> a source file that is compiled into a static archive (aka
> ranlib archive aka .a
> file) and then linked into one or more binaries. Xcode can
> have trouble
> tracing the source file through to its final destination
> bundles/dylibs/etc. The
> basic issue is that Xcode can't match a source file to a
> single installed
> binary -- there are many interesting ways people come up with
> to confuse
> Xcode in this manner. :)
I was in an intense hack/compile/debug/hack cycle when suddenly,
the breakpoints turned yellow/orange/whatever. What's notable
about my experience was that I tried to place breakpoints in the
main() function (this was a C++ Tool project with default
project settings).
Since this has happened to me several times in the past, then is
there a way, once it happens, to "un-confuse" Xcode? Assuming I
leave "load symbols lazily" turned on, is there a way I can
explicitly tell gdb which executable the main.cpp file maps to?
Alternately, is there a way I can "reset" the confusion? After
the confusion started, I resorted to deleting the project files
and creating a new project. For that reason I think whatever
causes the confusion gets stored or cached in those files. In a
large project involving many modules, creating a new project
could be a major effort.
I appreciate any input someone might offer.
Thanks again,
Soong
_______________________________________________
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