WWDC2003 Session 308

Transcript

Kind: captions
Language: en
hello so those here there at the
devtools feedback form this time I will
try to stay on the stage some people
were there that's me so we're just going
to do a little bit of an overview of
debugging and then we'll get into a
little bit of detail some of the stuff
you would have seen before if you've
seen the other xcode sessions but I want
to go into how some of the features work
a little bit so we'll go over how to get
started I'm going to go over a little
bit of tools to show you how crash
reporter works in Panther and then we'll
go through some you I with Scott Tucker
will come back we'll do some advanced
gdb command line work and then we'll
have some demos so what you guys
probably you know if you have to use the
buggers a lot you know maybe you
shouldn't be doing what you're doing so
this is kind of I kind of look at
debuggers as you know a crutch for my
friend program has a problem how can I
help my friend fix my problem so so what
is debugging you know why does it crash
why's it hang what happened you know the
box is green instead of blue or the
number is 5 or my fractal is weird you
know but it's all your friends program
so don't don't worry about it don't feel
bad so what do we give you as part of
Xcode so in addition to what you think
of is debugging there's actually a lot
of tools on the system that we've kind
of talked about in other sessions as
performance tools like sampler and Malik
debug and even the chudd tools but those
are all actually very useful for
debugging too and we will go into a
little bit of detail of how to use
malloc debug later no no demos on that
but we're just going to get real nerdy
and talk about it but you know if your
program is hanging or crashing sampler
and malik debug can be very useful
before you start dropping down into gdb
or using the debugger you I inside Xcode
so crash logs if you've got a program
that crashes you probably want to find
out what happened and where it crashed
so there's a most
you guys should know this but the
console application under applications
utilities has a preference to enable
crash reporting and that actually gets
set on by default I believe when you
install the developer tools but there's
also another preference you can set that
lets you have the crash thing pop up
this is your application crashes you'll
get a window up here this has changed a
little bit from Jaguar to Panther so now
the logs actually appear in your home
directory library instead of the system
library and instead of getting separate
windows for each of the crash logs you
actually have a drawer on the side he
played with the Panther preview you'll
be pretty obvious as to what's changed
so what's in the log the log has a stack
trace for all your threads it's got the
register state for the thread that
crashed and if it crashed in an area
that has debug information it also has
the file online number some of the
things to be careful about is if you're
writing a program that crashes a lot
during your development cycle these
files get bigger and bigger as each
crash gets appended to the end of the
log and they stay until you delete them
they don't go away after you reboot the
system they are not considered temporary
files so be careful and manage a crash
logs if you're crashing a lot so when I
say debugging I generally mean gdb and
debugging see based programs and the way
that works inside Xcode is there's
actually three separate distinct unix
processes involved there's the Xcode you
I there's a GDB debugger and then yours
your target application and they all
talk to each other the different IPC
mechanisms to communicate Xcode and gdb
actually are very tightly coupled for a
lot of the features as you'll see in a
little bit and then gdb of course is
going to issue low-level calls down to
your application lock level calls
actually to control and single step and
collect exceptions from your program so
Xcode is really just the gdb user
interface when regard to debugging
courses a lot more from other sessions
but we're talking about debugging here
so what is it let you do let you view
fret
view threads and stack from local
variables and you can type in
expressions and it'll all be displayed
you can set breakpoints you can
basically not type gdb commands and
debug your program and see results and
interactively iterate over your program
the important thing is all these cool
new features that we've been talking
about all week like six and continue
zero link which really isn't a debugging
feature but six and continue mostly and
these new data for matters these are
things that are only accessible via the
Xcode you I do not try to access them
from the gdb command line because they
will not work Xcode also has support for
debugging non-si based languages like
JavaScript and Java but we're not going
to talk about that at all today so what
do you need to do to make sure your
program can be debuggable if you have a
new project that you're creating with
one of the Xcode templates or if you are
upgrading a project building project the
development build style should set the
correct preferences for you in your
project and when you click build it
should just work if you have an older or
legacy projects that you're bringing an
open source project that uses make files
or some other build system that you want
to integrate into Xcode you need to make
sure that you pass the correct flags the
compiler to enable debug information
generation and on GCC that's dash G and
also you need to make sure you turn off
optimization we do not deal with
optimized code right now very well it
may work but you may see some weird
things as you're debugging your program
you can see the line stepping back and
forth as you say step so you could get
confused so one other thing is if you're
debugging a framework you need to make
sure that you set the path to your debug
framework and not the if it's a system
framework that's installed in system
library frameworks you want to make sure
that you set the path correctly to the
debug library and that's in the
inspector for the framework or for the
framework in the UI and please use an
absolute path there
because otherwise it will try to be a
little too smart and you may get the
wrong thing oops that didn't work so
what's new so I kind of briefly touched
this custom data for matters you've seen
and heard about in previous sessions if
you've seen any of the tools sessions
fakes and continue we've been talking
about all week we've also added support
for stopping on catching and throwing a
C++ exceptions and we've cleaned up the
gdb the debugging you I in Xcode and
hopefully we are minimizing the amount
of time you have to type it to get the
gdb console prompt so data for matters
why are they good what they do is they
allow you to summarize data if you've
been using project builder and debugging
and you have a complex data type you've
got all these turn downs and it can take
up a lot of screen real estate to show
you're either class hierarchy or
substructures or elements in your
structures so you can actually create a
formatter to display that what you care
about a one-line we also support custom
plugins for the data for matters the way
it's architected right now is you need
to have a function that returns a value
which is great for cocoa but carbon
api's tend to pass things by reference
return values return values by reference
and return an error code is the return
value of the function which you really
don't want to display the error code you
want to return display the the actual
data and so we have a plug-in
architecture that you can write your own
for custom thing or we actually supply a
bunch of system types and I will kind of
encourage you to attend tomorrow morning
9am session bright and early after the
party tonight where Chris Espinosa will
go over that in detail you can also
annotate things with text so if you have
I think you saw this in in Ted session
earlier in the week if you were there
where you can actually say you know this
is my x coordinate y coordinate etc so
it's very easy to see at a glance what's
going on there's also some expression of
that can happen important caveat or
things to be careful or cognizant about
is the formatter itself actually bound
to the type of the object that you're
setting the formatter for it's not just
that instance of the type so if you have
a local variable that's an nsstring or
an integer or whatever and you set a
format string on it that format will be
applied to all displays of integers or
NF strings in your entire debug session
maybe sometime we will expand that but
right now for this release it's going to
be single formatted string for each type
and we actually have 35 for matters for
carbon system types right now that list
can grow that covers most of them we're
also shipping a bunch of base cocoa
foundation for matters so out of the box
you will actually get a fairly good
experience of these opaque tights that
carbon tends to pass around so not
working so I wanted to bring up Scott
took her and he's going to give you a
little overview of the UI and how it's
changed and why you want to use it
so what we're going to be looking at
today is sketch it's common very
well-known I'm objecting to the example
we ship on the system and just to start
and just bring up the great point I've
actually set a breakpoint in STK graphic
so that when we go to draw a rectangle
it'll break and so let me just go ahead
and show you one thing that we've had we
had the old project euler we continue
have an Xcode but people asked from time
to time is how do i set up you know a
symbolic break point i want to break on
raise i want to break on a function
named where I don't necessarily have the
code well if you go to the debug menu
show breakpoints you can actually just
click new break point and then type in
and then that's actually just passed
directly down to gdb when they set a
breakpoint and it's easy as that you can
hit you can obviously just hit the
breakpoint get additional ones we also
in the breakpoint columns and see we
sort them by the file there in and all
that so so let me go ahead and bring up
the bug so first I just wanted to go
through the interface real quickly here
this is the default layout you'll notice
so here we have your threads we have the
summary and we have the editor and here
let me actually just get it popular with
data and so you'll notice here is that
four areas that we have symbols and we
have access to source code information
we will show you in black and so for
example if I go to like in its
application well I don't have appt kits
source code on my machine right now so
that's in gray and also you'll notice
that because we don't have the bug
symbols we don't have any pop we're not
populating over here but when you do
will show the variables over here and
we'll show the current line we're on
this is the break point it's a great
part the red point is actually the pc
and i'll get back to that in a little
bit so what I'd like to do here is show
you the different let's show you the
other de Burgh layouts we've got
feedback as some people really didn't
like this style of layout so we actually
have two that you can choose from in
this one for those people who either you
have you know long function names or you
have a lot of variables you can do it
this way either one we actually have
this little widget here that controls
all three windows because we got the
feedback that oh you know it kind of
sucks when I have to have to drag one
way and then I have to find another way
to drag out the other way and I really
want one place to just control all three
panes and so we added that it really is
the small stuff it's amazing so the
other thing I wanted to show you is the
console drawer so you know in project
builder we had this little console
drawer only fortunately small screens
let me pull it up a little bit and here
it is you can get access to gdb but we
did get feedback that you know some
people are like I don't really want to
draw you know I'd rather just have a
separate window it's a lot easier for me
if I'm gonna do a lot of gdb stuff to
make it really big
egg so we now have its own little window
[Applause]
let's go ahead and hit continue let me
just bring up a dub said what's going to
be fault so what I want to show you now
is I want to go into a little bit about
how the data for matters work and so
forth so for this example I'll go to my
break point again and let me actually I
want to switch back to the other
girls I prefer the other debugger
buyouts are so if I was really cool I'd
be using demo assistant and if I was
really good typist I just type it in I
am neither so I'm just going to copy and
paste and so what you've got here is
I've actually I'm going to go through
these in order this first one what I'd
like to do is a lot of times less
objective c you can run into retain
release problems so i want to quickly in
the debugger to see okay what's my
retain count on this object so what I'm
going to paste in here basically is
saying okay I want to get an integer
back and basically I'm asking the
variable self what's your retain count
so for retaining that return that it
comes up as one well that's okay but you
know it's kind of confusing because one
what so I guess one thing I could do is
I could just add the retained count well
that's great too but you know the nasty
thing with self is well what is self I
can't tell from here I mean I could go
down and I could look for is and all
that kind of crap but that's lame i want
to be able to do it right here so let's
go ahead and add this beginning part
we're and i'll just stop here for a
second just point out that what I'm
doing is I'm basically asking the isn't
for the name property and then I'm
saying okay I want to return this is a
string and I'm just pretending that to
the front of what I've done here already
so now you see I get SDK ranked angle
you like oh that's great scott but you
know does it really work you know what
if i do something different so let's go
ahead and hit continue
there you go so now I've got this nice
little formatter that for herself on all
these SKT graphics it's going to show me
oh here's the class and here's the
retained cam and we think this is going
to be very useful for people when they
need to get custom information quickly
when you're in a tight loop or you just
don't want to have to dig down deep and
open up all the little twiddle triangles
to see what you really want and I
believe and at this point I believe I
I'm done taking a joke thanks Scott so
that actually was a pretty good very
simple demonstration of how powerful the
custom data for murders can be we're
looking for feedback on how we could
improve them adding different format
strings what you think would be useful
so any input would be greatly
appreciated so now we're going to spend
some time talking about six and continue
so you've seen it what is it what does
it really do I mean why do you want it
it really is debugging without stopping
your program and and probably the most
important use of this is you've got a
program you've been dug debugging it for
hours and you find a problem it'll take
hours to get back to that spot in your
in your program run again you don't want
to take that time so you can make a
change continue debugging and you save
that our to that it would take to get to
the state that caused the problem so
it's very important to note that this
does depend on tight integration between
Xcode and gdb Xcode is telling gdb which
files are changing which binaries are
being recompiled and how it out and how
and which source files associated with
so again I will say it again and I will
say this many times this will not work
from the command line and also this is
not the panacea of changing there are a
lot of things that just won't work and
I'm going to go through how this is
implemented it kind of a high level and
in the hope that it will help you
understand the types of changes that
that won't be allowed other thing this
only works with GCC 33 because of
some compile code generation options
that we needed to have and it does work
with zero link enabled so you don't have
to worry about what your zero link
setting is for this feature to work so
actually I covered this out of order but
yes it's the other thing that this is
useful for in addition to taking a lot
of time for long running programs is for
certain types of things you can do
prototype style development if you're
debugging you can do quick changes
modify the behavior of a class or
procedure and just keep going until you
get it right so how does it work so here
we have a simple simple program with a
main and two subroutines I chose C just
because it's easy to to show on the
screen but six and continue works which
the objective c and objective c plus
blossom c++ so here we have main making
call to foo let's see if i get these
clicks right for all the animations this
is going to be fun so boo runs and you
find a problem in foo you're in your
debug session there's a problem what do
you do if you go and look at your source
another click so then you're going to
edit your file you're going to recompile
it and click on the little tape
dispenser Fix button and what that does
is it tells tells Xcode to tell gdb to
reload that file and what actually is
happening is GD b is actually loading
another little bundle which i'm calling
fixed foo in addition to the old version
of food which is in memory and in
addition to it loading that what gdb is
then going to do here we go is it
actually scribbles on the first few
instructions of the old foo routine to
point to the new food now you might
think why should I do that why don't we
just you know get rid of the old one and
use the new one well you could have a
function pointer to foo that you still
want to have it be valid you could have
it stashed in the global variable
somewhere and so we actually keep all
the old data right or the old pointers
valid so after that scribbling happened
actually I should point out before I go
on that we also do fix up references
to static global data also at this time
too so if you're referencing a global
that happens to be in that module the
right thing should happen so let's get
back to the flow here so now I'm later
out of my program and bar wants to call
foo so it actually is going to jump to
foo the old version of foo because we
don't want to patch all calls to food a
point to the new one that would take a
lot of time so it's going to vector
through that little jump thing that we
scribbled at the beginning of the old
version of foo and end up in fixed foo
and then that's going to run come on and
it comes back and returns just like who
would have so that is kind of a very
simple version of what's happening and
see the engineer that implemented this
has got a big smile on his face saying i
simplified it way too much but we can
deal with that during the questions
later because that would take a long
time to really explain all the details
so limitations so it doesn't support all
types of changes I mentioned that
earlier what we are hoping and what we
will be doing over the process of
releases of Xcode is that we want to
have common unfixable changes flagged by
the IDE and again do not try this from
the command line it just won't work so
what doesn't work what's what what types
of things aren't going to work so if
you're going to be changing structure or
class layouts that actually is going to
cause different code generations or
references to other from other pieces of
your code that's going to run you into
problems changing function signatures
again because you're not recompiling the
whole program you're just recompiling
pieces of the program adding global or
static data in the module since the rest
of the program won't know about it you
won't be able to access it anything that
needs initialization like static
initializer either C++ or C because the
initializers won't get run when this
thing gets reloaded and again virtual
member functions similar to to changing
class layouts for the same reasons and
also in addition if you're trying to
modify a function that is at the top of
the stack currently active changing
local data is a bad thing to do is also
because you'll be changing the
frame that's currently in memory and
that would confuse a lot of things and
also if you are adding something that
gets initialized like you know even like
I equal five earlier in the function and
where you are and you want to reference
I and expect that value to be said that
won't happen because we continue
execution from where the pc was before
so what does work that sounds like a lot
of things that don't work but in fact a
lot of things do work as you've seen all
week common logic errors tend to be
something that are easily patchable off
by one errors I forgot to x 2 etc all
those things should be fixable you can
also add new calls at new logic to
existing routine no problem you can
delete code you can change constant
string constants integer constants
whatever and pretty much any other
common operation you can try it and if
it works great if not the hope is that
what's going on what's what you can
always if the fix fails and the IDE
tells you the fixed value can always re
run your application from the beginning
and it's our goal that over time we
actually increase the amount the types
of changes that are allowable to be
fixed and we get a lot better doing
error detection if it finds an unfixable
patch so I bet you can find some things
that crash your debug session today with
the preview but again we appreciate
feedback if you find those and have
something that's reproducible and we can
fix it either for the GM or for the
release after one caveat with the
preview also is right now if you do a
bunch of fix and continues and then want
to rerun from the beginning the build
system isn't quite correctly hooked up
so you will actually lose those fixes if
you rerun because it doesn't know it
needs to recompile there's actually two
different datos that get generated it's
kind of a bundle that gets fixed as
opposed to your regular dot oh that
would get linkedin or 0 linkedin to your
application and that'll be fixed for the
GM but right now
I'll make sure you click build and run
instead of just run after you do a fixed
and continued session so again I'll
bring Scott back up and he's going to
show some more fix and continue so
already you've probably seen this
several times now and you'll notice that
one of the themes before was we always
were showing you without showing it
without showing you the debugger active
at the time we kind of hit off the
debugger and you were just editing and
you do a fix and woo you know you're all
excited so what I'm going to do is now
focus on well what if you're doing a
debugging session you're paused and you
want to do a fix you know what's the
experience like they're so what I'm
going to do is I'm going to start
debugging sketch again and let's use
that same breakpoint and so what I'm
going to do so we're stopped and we're
about to draw and so what I'll do is I'm
just going to comment out some lines and
uncomment out some line so we're going
to change the color to red and let's see
what else and let's change the stroke
line width 28 for example and so I can
go ahead and do fix and then I'll
continue huh okay so i got the stroke
language but i didn't get the the red so
is jeff pointed out you know we remember
where you are in the function so when
you fix the function will take you back
there and continue on so one thing in
the demos we've done before us we've
done things worth always refreshing but
just only remember when you're in the
debugger that we're just going to
continue on from where you are so that
brings up the next thing which is well
what if I wanted to have it actually get
that fixed well it would be really cool
to be able to move the pc wouldn't it
well guess what so let me go ahead and
let's just just to show that something
is actually going on here we fixed it so
now i'm going to change the color to
green and i'm going to go ahead and I'm
going to fix but let me take this to say
they're freezing there and let's
continue oh thank you
yeah this is what I get for being cocky
let's try that one what let's try that
one more time
it's not
Oh
yeah this is an okay well we'll do one
more fix so let me go ahead and do the
thick good absolutely oops no no
continue so what we're going to let me
let me just let's just catch up here so
let's close this file just so we can get
rid of the clutter open up new one okay
so for example let's change it to let's
change it back to let's change it to
black so we'll just get a black one so
just to show you that i really i'm not
using all this to just divert the
attention but so i'm going to fix oh
I'll go ahead and fix this and then I'm
going to drag the pc back and so then
i'm going to say and i'm also going to
just for disabled that and let's going
to you there you go one more thing we
wanted to show you i'm at jeffs request
is there will be several times when you
do something and it doesn't fix so we'd
like to show you a case of where that
actually happens so when this comes back
is failing it's supposed to fail so i'm
going to go ahead and I'm going to turn
this great point back on and then let me
go up here and I'm going to go up to the
top and so as different you know I
really shouldn't do this but I'm not
listening to Jeff because I know what's
best and I'm going to fix it air in the
future we want to have a much more
apparent well for one thing we want to
show you the entire error and not just
cut it off but we'd like to have like a
panel or a sheet come down telling you
that a fix has not completed and over
time like Jeff said we want it to be
more kind of have more feedback that
okay this isn't going to work so you
don't even get any situation and that's
one back to you Jim alright thanks
[Applause]
so I seem to have been talking very
quickly so we're going to have a lot of
time for questions at the end which is
good for this type of session so I'm not
a couple things that we have added
you've seen this i think in one of the
sessions earlier in the week is we've
added support for stopping on catching
and throwing of C++ exceptions which is
well a often requested feature for C++
programmers it's a very simple UI to
show I don't know if you caught it when
Scott had the debug menu pulled down but
there's two menu items under the debug
menu stop on C++ catch stuff on C++
throw and then it just stops you get a
stack trace you can see what's going on
you can also do a little bit more
sophisticated things from the command
line which we'll talk we'll talk after
or clean might actually cover it when
he's talking about the command line so I
think I talked about a lot of these
caveats already but I'm going to go over
them again the first one I didn't
mention but yes the custom for matters
are really cool if you notice they
actually have a lot of code in them or
can cause a lot of code to be executed
in your inferior debug process so if you
have you know hundreds of them on your
screen you're starting and stopping your
process a hundred times and getting a
value back to GD b this can cause single
stepping to be slow and you may want to
disable them and if you're stepping and
then re-enable them when you care also
it's important that since you are
actually executing code in the debug
process that you do not take code that
might cause a deadlock to happen so if
you know you're debugging some graphics
thing and a core core graphics routine
in the system has a lock held and you're
waiting for that lock to as part of your
data for matter that could be a problem
depending on when that data for matter
is called and also for the preview
release right now we hope to improve
this over time large 0 link applications
could slow down your debugging and what
I mean by that is time to display the
stack or times the single-step as it's
dynamically faulting in the modules as
need
and it could take a few seconds right
now you may see that and we're going to
try to improve that for the final
shipment for the GM so with that I want
to bring up CLE Dean is a senior gtb
engineer and he's going to talk about
how to use this stuff from the command
line hi so for the most part the things
that we do on the GDB command line are
things that we hope to have be in the
background we want to be things that you
don't pay too much attention to so for
the next five or ten minutes I'm going
to take those things into the foreground
and hopefully tell you one really cool
feature that we've added and then a
couple of neat things that you've always
been able to do but you might not have
known you were able to do so our new
feature is cash single file support this
is basically a feature that's designed
to improve the startup time of gdb by
letting you take large symbol files and
have them get stored on disk so that
when GDP goes to read them instead of
reading them you know you'll see little
dots go across your screen as a simple
tiles get loaded the goal is to have
instead of being dot dot dot it should
just be done a lot of people have said
hey we really wish you be started to be
faster we'd love to make it so that it's
always instant but the least we can do
is make it so that it's a lot faster the
second time you do stuff it's just a
cache it doesn't change anything about
how process and symbols should do
everything exactly the same the only
goal is to make it start at the program
a lot quicker and get you to bugging a
lot quicker the way works right now is
when you install a new developer tools
on your system it builds a cash for all
the system libraries on the system and
it'll go ahead and use those as a build
those just once you can optionally tell
it to create a cash for your user
binaries I'll tell you how to do that in
a few minutes so this is the first time
we've shipped this there's as always a
couple of things that can go wrong the
very first one is sometimes those caches
can get out of date the way you'll know
that they're out of date is you'll see
the big warning it won't be read on your
system but it'll be there and it'll say
pre-compiled simple file is out of date
don't panic all that means is that it's
going to take another couple of seconds
to load the symbols should be exactly
the same as if they weren't there at all
you can Oh at any time you can update
them there's a command I don't know if
you get the sliding this but it's you
know pseudo or as you do and there's a
command user live exact you to be cached
in files and that will regenerate the
whole cache for the whole disk similarly
if if you think something's going wrong
just don't trust them for whatever
reason you can delete them whenever you
feel like and you can recreate them
later if you discover that it wasn't
actually that was causing the problem or
whatever else or if you just want to
update them so the reason that we didn't
make this always the case for all
binaries is that a it's a new feature
you want to get some use of it out in
the field before we make it the default
for everyone but also that sometimes you
don't want it so if you have for example
a lot of binaries that don't change very
often and you just change one thing and
one part of it like you have three
frameworks an application it's great you
can cash the simple files for the
libraries start up the application
everything's quick if you have one giant
massive binary it might not be so quick
necessarily because there's a little bit
of overhead and creating a cache so if
you just had to regenerate that cash
every single time it might take longer
to regenerate the cache then you'd say
by starting up so to get around this for
right now we've made it something that
you can set on a per project basis so
basically in your per project directory
there's a file called gb in it that will
control how gdb paves and if you set the
variable generate pre-compiled
simplifies to 1 it'll go ahead and
create those cast symbol files for every
framework that's loaded by gdb is she to
be seasick so the idea is that the first
time you've debugged a framework that
you've written or some other object that
you're writing it'll be it'll take
another second or two to load it up but
after that it'll just be done just like
we're hoping the cache files are stored
in a directory with your
object called igb simple cash if you
want to disable it you can just remove
those files if it's project builder
there's a cool thing since project
builds our stores in this build
directory generally all in the same
place those will be shared among the
project builder files which i think is
kind of neat so you know I'd love if you
can try that out you know be sure please
let us know how well it works for you if
it's really affecting the performance
that is really improving influence
really hope it does so now on to a
couple of neat features in gdb these
have been there for a long time but
they're still really the first one is
watch points which is basically a way to
have gbb stop when some expression in
your program has changed so the most
useful part of this is when you want to
find up a data value has changed you
know typically it's for finding memory
crashers or you know something in this
library is changing some data variable
of mine and I don't know where it's
getting changed on how it's getting
changed but I sure know that it's
bugging the hell out of me that it got
changed and I want to know where so what
you can do is at any point you can set a
watch point on it any on an expression
it can be any expression is valid in
your program it ideally shouldn't be
something that call function calls but
you know any valid SI expression is a
valid watch point expression and what
it'll do is GD b will protect the memory
pages that are involved in that
expression and whenever they get
modified it'll stop it'll check the
expression check the old value and it
will see if it needs to report the value
has changed a couple of caveats is you
know if you change that value all the
time gtb is going to be stopping your
program all the time that's going to be
slow if it's changing it constantly
particularly if it's something on your
stack because you know everything is on
your stack that's going to be getting
modified constantly it's going to be
stopping constantly going to have to
start the inferior over and over and
over again that's going to be very
unpleasant experience but for things
that are in global data things that
aren't access constantly it's a
tremendously valuable feature
particularly for you know I don't know
it's trashing my memory so sort of the
classic example of that is to watch a
buffer and say you know who changed this
buffering
be in my example there's this little
cute little curly brackets around stuff
which some of you probably seen before
some of you haven't with that saying is
just take the variable buff and treat it
as if it were an array of a thousand
twenty four characters so that's
basically a shorthand for tell me when
anything on this page has changed i want
gdb to stop tell me what on the page has
changed and give me a back trace so i
can figure out exactly how i got to what
was doing that another very useful
feature is breakpoint conditions it's
basically the ability to add a
conditional expression or a set of
commands to any break point or watch
point so with that let's you do for
example in the case of watch points is
add extra condition so you can stand I
just want to stop when this has changed
I want to stop when it's changed to ten
or I want to stop when this pointer has
become invalid or you can use it for all
kinds of crazy features in the second
example you'll see what we've done as we
stopped on the open call so we said you
know whenever I open a file no matter
how whatever reason I want you to stop
and then I want you to tell me what
violão so since the arguments always
going to be in the first argument
register r3 we can just have it print
out the file that was open cast it to a
string and continue on the way so you'll
see as you're running your program is
just a big output dumb of you know
loaded to open this open this open this
open this right down the line it's you
know I'm sure there are other ways to do
that exact same thing but it's neat that
you can do that without having these any
special features just by setting
breakpoints and putting logs and some
people have done some very impressive
things with just bright boy conditions
you know to log of programs while we're
on the topic of memory smashers I want
to talk a little bit about some other
tools that are out there for debugging
memory smashers the best thing or one of
the best thing malik debug which is a
tool that is designed to help badly
behaved programs crash for you so what
it'll do is it will overwrite free
memory after it's been freed and it will
add guard pages before and after
our memory Malick's regions so that when
you free something if you go to write to
it later it'll occasionally check to see
hated you just write on something you
shouldn't have did you just overwrite
the buffer or did you write before the
beginning of the buffer and it'll
generate logging messages for you the
main reason I mention here is that it
actually works really well with gdb if
you run a program both under Malik debug
Angie to be at the same time you can set
break points at the mounted bug output
routine so if you set a breakpoint
exceeding example Malik printf Malik
debug will stop in the debugger let you
get a back trace of exactly what's doing
the wrong thing and let you you know do
normal the bugger operations on that so
you can look at the back-trace find us
how you got to the things fresh in the
memory and you know go about fixing that
for more information on that you can
just check out the help menu in the
Mallik debug documentation and there's
actually a pretty sizable chunk of stuff
there on how to do that the last one is
on the topic of connecting up to things
of your running under something else is
the GDB attached command this is
something that I know we'd love to have
an Xcode I don't it isn't in there yet
so for right now you can pretend it is
by doing it from the GDB command line
it's a very simple syntax you just
basically say attached and then the name
of the program or the name of the
program follow the process ID or just
the process city by itself and well gee
dub you lose our connect up to the
program you're debugging and it's pretty
much just as if you ran the program
under gdb except that you could run it
under something else and this is really
great for programs that are hard to
attach to you know say they might have a
complicated startup routine they might
be you know expecting to be double click
from something or a plug-in from
something we use it for debugging the
finder it's a really handy way to hook
up to something without having to figure
out all the complexities of how to get
it started exactly the way it expects to
get started it's also very handy way to
hook up to something that's a running
under Malik debug or running under
sampler or running under both at the
same time even the one thing that people
have problems with this way well how do
I debug something
it's you know writing the very end knit
code of this thing that I'm double
clicking on the easiest way to do that
is you go ahead and just stick a fleet
call right in the beginning of your
program and what'll happen is when it
runs it'll start sleeping when you
attach you'll be stuck at the sleep you
can say continue and I'll just continue
right on from there which is can be
pretty handy we also ship a command line
version of the sampler tool which is you
know basically a handy things you can
run you know sort of XML gtb is a my
version of sampler so syntax pretty
simple sample you can give it a process
ID just like you to be attaches to and
it'll write it out into a file and /
temp that you can look at later I'm told
that if you play some games with it you
can actually read that into sampler app
but I probably want to check the release
notes on that to know how that would go
you can also use that just like you use
gdb attached so if you've got something
that's already running and you want to
know how you know exactly how its
performing instead of having to figure
out how to start it under sampler you
can just attach to it just like you
could with GV and back to Jeff thanks
CLE so just a couple more things to wrap
up and then we'll go over to QA we're
not nuts we're not too short so you know
one of the things I want to get across
is this is we've done a lot to try to
improve your debugging your development
productivity by improving debugging and
yeah I made the joke at the beginning
but we all right bugs and the best way
to fix the bugs is to find them as fast
as possible and the tools are very
important to do that fixing continue its
great play with it as much as you can
feedback definitely appreciated we know
there's problems with it this is a first
shot at this technology we want to make
it as robust as possible in time for our
GM
when Panther shipped custom data for
matters you saw kind of just a real
quick brief demonstration of how
powerful that can be but remember lots
of them can make your debugging
experience flow and then CLE talked
about cash sim files this again it's
it's brand-new one thing I don't think
Lee mentioned was that we actually had
install time generate cash files for all
the system libraries so these are
actually there by default CLE was
talking about how to generate the caches
for your own private code so how to
learn more there's documentation and
Xcode from the help menu Matt Morris has
shown that a number of times this week
already how to access that and that
we've actually spent a lot of effort on
that to search look man pages for gdb or
on the system release notes for the
compiler actually are helpful for some
of this stuff so make sure you get the
right settings for debugging and
standard documentation which don't need
to go through who we contact Godfrey to
Georgie there's email email should go to
him there's also the Xcode feedback mail
list and bug reporter for Boggs please
please file bugs in the past people have
complained about gdb in the debugging
experience and have not filed bugs and
we look at bugs we fix bug we don't fix
bugs if we don't know about the bugs or
if they just appear in a mailing list at
some point they will be forgotten when
we're going through a bug list so please
please file bugs and bug reporter and
the mailing list do provide lots of
information and help for people so it's
the end of week there still are a couple
more sessions I need to plug for crisps
in the morning 9am bright and early he's
going to go over debugging and tuning
carbon apps and he will spend a
significant amount of time talking about
how to write custom data format or
plugins for carbon types and please
attend if you're interested and there's
also a discussion on software test tools
later in the day Friday so with that I
would like to bring up Godfrey to keep
me under control and everybody else and
the GDB team and the rest of the QA
panel if our QA panel with complete come
up thank you very much chef it was a
great job by the way a comment came up
earlier today that the Xcode feedback at
group that apple.com address was not
accepting email if you send to that
email please copy to my address above
that that way that's a good test for me
to see whether it has actually gone to
to the to the mailing list we've reset
the parameters this morning and I'm just
hoping that are not missing any comments
you're sending in because we haven't
seen as much as we had expected as yet
so please send us our send us your
comments copy them to me I'll make sure
that they get to the list one way or the
other okay