WWDC2003 Session 310

Transcript

Kind: captions
Language: en
morning everybody welcome to session 310
debugging and tuning your carbon
applications with Xcode if you do not
want to learn about debugging your
carbon applications with Xcode now would
be an excellent time to be playing this
is actually going to be a little more
focused on debugging than on tuning
Robert bowditch do that excellent
presentation on the performance tools
yesterday and I saw three plugs and
sessions yesterday pointing to custom
data for matters so I've changed the
content a little bit to focus more on
the debugging and custom data formatting
because most of the stuff that Robert
explained on tuning and diagnostics
applies just as well to carbon
applications of de coco applications so
if you missed that catch it on the DVD
there's some excellent stuff there I
want to talk about carbon not just for
codewarrior anymore we've been designing
Xcode so that it's a great carbon
development environment and putting a
lot of emphasis on carbon debugging in
the debugging environment Panther and
Xcode have some really great tools built
in to help you build and debug your
carbon applications what you're going to
learn in this session today are some
basic differences between the carbon
debugging you may be used to on Mac OS 9
with Max bug and the code warrior ide
debugger and what you have in Mac OS 10
with gdb and the Xcode debugger there's
some techniques for using gdb and and
Xcode to debug carbon apps some secrets
that are hidden in a on apple's website
in plain sight in a file called carbon
tips and tricks if you haven't read it
that's what I stole most of this
presentation from some new features in
Xcode that you haven't seen before that
aren't on the web that are really cool
that it will not only allow you to debug
your application build custom debuggers
in your application but also see a lot
of your familiar carbon data types right
in the debugger with no further ado and
then some carbon specific performance
and tuning trip tricks I have like one
or two slides on those like I said let's
go through the steps in debugging and
tuning this should be familiar to
everybody
first you have to define your quality
and performance goals i think if you
remember from the mac OS 10 presentation
the way we got safari so fast was that
we made no performance regressions a
requirement so if you really want to
deliver a performance application if you
really wanted to deliver a quality bug
free application all of the tools in the
world won't help you if you don't have
the methodology and the discipline to
make sure that the tools are used in the
process so everything I'm going to show
you today it's great if you know it it's
even better if you define a process that
makes sure that these get used for
example distributing these custom data
viewers throughout your organization or
building them into your product build
process rather than having them on a per
engineer ad hoc basis you need to prep
your project for debugging and we're
going to show you some ways to set up
some environment variables and set up
some build settings to make your project
more debuggable that are carbon specific
get your basic functionality working run
your app in the debugger and isolate
bugs then run your then when you get the
bugs out run your app under the
performance analysis tools to see if
you've met your metrics and its really
pretty important to make sure that your
application works before you really
start to use the performance tools on it
because the performance tools far prefer
a running application to a broken
application and then you iterate and
iterate and iterate your friend is GD b
I know a lot of you don't believe that
but GD b is the underlying debugger in
the mac OS 10 system and it's really
going to help you out if debugging
without gdb on Mac OS 10 is like
debugging without max bug on Mac OS 9
you can get pretty far with symbolic
debugging and what the debugging the IDE
shows you but unless you know what's
going on down at the middle level you'll
never really know what's going on with
your applications so if you don't have
any familiarity with gdb you really
should acquire some in order to do great
debugging on Mac OS 10 we're going to
show you some of the basics today and
then some of the interactions between
the ibe and gdb the basic way to launch
an application in the debugger is to
from the terminal you issue the GDD
command and then the path to your
application and you need to go into your
application and all the way down into
the package of your application the dot
app / contents / mac OS all the way down
to the dy LD executable if you just so
this is people people's first mistake is
they try to gdb the package gdb the
executable second thing you can do is is
just you can attach to a running
application launch your application
launch gdb and then attached to it so
you have two modes launch it inside VDB
or attached to it once it's running if
you've used any other command line
debugger the commands that are
conceptually familiar even though
they're probably under different names
be sets the break point P displays the
variables value so you have to print
variables rather than just type
expressions X examines memory and that's
like DM in max bug see continues
execution after a break point and BTW
prints the back-trace if you're used to
FV and Max bug it BTW in gdb we're all
grown up so we can learn to new to
letter acronyms what's great about gdb
is that gdb while it's stopped in the
inferior let's you evaluate expressions
and call functions within your
application or within the framework and
this is very powerful and this is the
first technique we're going to show you
that there are a lot of debug only
functions built into the carbon
framework that let you figure out what's
going on in your carbon applications in
ways you wouldn't normally be able to do
many of these fulfill roles that were
filled by D commands in max but these
are now instead of being in the
development environment or in the
debugger they're built into the
framework and you just invoke them from
the debugger it's a pretty long list but
you can print debug info for H I objects
or window groups you can print the event
queue or watch events coming in you can
print the menu lists or menus or menu
items or win
you can even / the VIS region region or
the update region of a window just to
see what it happens to be at this point
these are all listed in the carbon tips
and tricks document on the web which
I'll point you to at the end so you
don't have to scribble furiously now and
get the parameter list right by the
point is you can call any of these from
gdb while you're paused in your
application to see what carbon thinks
your app is doing so to demo some of
these I'm going to bring up Chris
Neville on keyboards we're going to
start with an application called
appearance sample which is on your Xcode
CD this copy of appearance samples been
updated to build a native project and
what we're going to do is we're going to
invoke it in gdb we're going to start it
off in gdb without using Xcode it's
already been built and gtv loads and it
runs the application and there you go
now to interrupt a running application
from gdb you just press control C and it
stops it and there we go we're
interrupted you can do a stack trace see
where you are things like that now we
want to ask carbon what a couple of
things are going on so we're going to
make the debug print menu list call and
we just to call void debug.print menu
list / and / n and we see this is our
menu list according to H I toolbox there
you go and it shows that the menu ref
chris is now going to do debug.print all
window groups and he's going to get a
hierarchical list of all the window
groups it's got the hex address and it's
also got the window group identifier
this will be very helpful in going back
to your nib or going back to your code
and figuring out what windows had been
instantiated at any time now he's going
to continue the application go back open
another window go back interrupt the
application again print the window list
again and now you see the new window is
in the window lists so this is a very
helpful debugging techniques from
to figure out what's going on in your
application we can go back to the slide
thank you Chris now I mentioned a little
earlier about preparing your application
for debugging and there's a technique we
use inside apple for the carbon
framework itself to prepare the debug
version of the carbon framework which
I'll show you a little bit later which
you can use in any carbon application
it's built into carbon there are two
header files called debugging H and
assert macros H which are part of the
carbon framework and if you include the
carbon umbrella framework you've got
these macros defined in your application
right now all you need to do is turn
them on a cert macros dot H if you look
at it is a whole list of asserts you can
throw in your application on various
conditions you can verify the things or
certain values you can verify the things
are not values you can think make sure
things are conforming things are nonzero
large number of macros you can use just
to make sure that your data is what you
want it to be and in your production
builds they all fall out and are no up
so if you are considering using
constructing a whole set of debug macros
that are in your debug builds but fall
out in your production bills we've
already built them for you they're right
there in a cert macros eh all you have
to do is define a preprocessor flag
debug set it to one and they're invoked
and then there is an additional
preprocessor macro that specifies the
level of debugging and we define four
levels for you and they have different
degrees of precision and explanation and
verbosity on the debug strings if you
set debug a debug internal that gives
you the source file in the line number
in which the assertion has been thrown
which is very useful for internal
debugging if you set debug external it
just gives the assert and the name of
the the string that was associated with
the
so your users can report that back if
you have debug break only then when Anna
surgeons thrown it just breaks into the
debugger and doesn't log a message and
then if you say debug production then
all of the asserts are silent and you
can set these either from the command
line either in include files and header
files when you build your project or you
can even set them in Xcode will show you
a little bit about that later there's a
second thing now like I said earlier the
debug version of the carbon libraries
every version of every mocco library
that we supply in the framework comes in
the developer release with two parallel
versions the debug version and a
profiling version and the debug version
has perhaps additional calls and
certainly additional console logging of
what's going on inside that framework
and if you build and link your
application with the debug variant when
you make system calls then those system
calls if you pass them bad values or if
there's a bad condition somewhere in the
framework it will do console spew this
is very very useful and not enough
people do it again you can control this
with an environment variable if you're
just running in gdb or you can control
it with a pop-up menu in Xcode and we'll
show you how to do that one thing about
using Xcode you have to turn off the
zero link in order to use the debug
variants of the libraries right now okay
and so will bring Chris back up again to
show you a couple of these things
so we're going to bring up the
appearance sample code in Xcode now and
go to a file called mega dialogue that's
right go to the switch pain method and
here's some there's some crude error
checking going on here this isn't really
very useful you know if the input value
is invalid then just do nothing maybe we
want to see when that input valid is not
input value is invalid so we're going to
put an assert here just verify what that
value is and that will cause the log
message if the pain index is 0 now
that's all all we type here the verify
macro in a certain macros does the rest
of the work now to to fire that off we
go to our project settings and get the
project inspector and go to our build
Styles because we want the asserts only
in the development build style and not
in the deployment build style so we'll
add by clicking the little plus box down
as corner and other underscore cflags
and it moves so you need to go select it
again not that one that one and we're
going to define the debug macro equals
one and debug underscore internal equals
one
and then we're going to build a project
and by defining those we're going to
activate those macros we're going to
define verify and it's going to run its
well not yet not yet come on build
errors and warnings hang on hang on turn
off zero well now zero link is in the
project settings
[Music]
it's not spelled wrong it's it's it's
it's build errors and warnings window to
build dialogue
clean build it's a development relief
folks GDB is also still running the
application that's okay okay
so now the application is built with the
debug flags he's going to run the
application and when the application
runs you see that the first time we call
that we get an assert that pain index
equals zero it turns out pain this
function is called with pain index
equals zero a whole lot now maybe that's
a performance problem or a logic problem
in our application maybe it's not but by
just silently returning we'd never know
but by throwing in a cert there we get
an interesting log to figure out what's
going on now you know just a couple
other things about this is that it shows
you the name third-party client well
that's the default name there's another
variable that you can declare that
defined in debugging dot H that if you
assign that preprocessor macro it
actually puts the name of your
application whatever you assign it in
there into your log so you can get
better logging messages and since we did
the debug internal style we're getting
the line number and the source file in
which the asserts happening so these are
built in they're very useful now we need
to quit the application and will show
you building with the debug version of
the carbon library which generates a lot
more diagnostic output not just a single
assert so what Chris is going to do here
is go down to into the executable
configuration and this configures what
happens when we run or debug our
application and you see there's a pop-up
menu to that says dynamic library
runtime variant the default standard and
we're going to set it to debug and that
means when we link our application and
we run our application we're going to
link it run it against the debug variant
of the library so if we build it and run
it
and open up the run log we see a whole
lot of output from the carbon framework
of interesting things that this
application this sample application that
Apple ships on the developer CD as an
example of how to write code all of the
wrong values that it passes the carbon
fray work so use this as a lesson this
is really very useful if you want to
know what the framework is doing as you
mouse around the application and as we
do things it generates even more asserts
these are asserts using the assert
macros and using debugging eight that
are built into the carbon framework that
are turned on in the debug variant okay
thank you Chris now he showed you a
little bit of debugging with Xcode first
we started out in gdb and then we did a
little bit of gdb style you know text
spewing from inside of Xcode now we're
going to show you a little bit of carbon
debugging interactively with the Xcode
debugger the Xcode debugger is a lot
better than the project Builder debugger
was I hope you saw in a couple of the
sessions like yesterday afternoon some
of the capabilities of it I'm going to
go a little more in depth into some of
the carbon aspects of that like any
other ide debugger it shows you the
execution threads it shows you the
stacks and the back traces where you
happen to be in the code it shows you
the source code it shows you the local
variables and it shows you the input
parameters of the functions in a way
that you can figure out what the values
are and what the variables are it also
lets you set and manage breakpoints
there's new debugging features in Xcode
we do c++ exception handling where gdb
and project builder did not is going to
be very useful if you have if you use
C++ exceptions as a routine part of your
application structure we allow you to
step through templates so templates can
be really really gnarly and if you can't
step
through them step through instantiation
or use of them it's really really hard
to figure out what's going on we do that
now in Xcode we've got some built-in
data viewers for foundation data types
and the most important carbon data types
you use and it's an extensible plug-in
architecture where you can define your
own not just for carbon data types but
for application specific data types as
well so now i'm going to hand it over to
chris and he's going to do his demo of
c++ exceptions and the stepping through
templates okay so what we've got here it
should look familiar to you if you came
to session 307 this is the power plant
appearance demo kind of the power plant
version of appearance sample we've
imported into Xcode so let's just start
this debugging loads run okay so here it
is we hang on again just shows off of
various control various kinds of windows
various kinds of windows hmm this isn't
working okay it's a bug how are you
going to fix it how indeed okay so when
this particular type of bug happens I
know from experience that if usually
because someone is throwing an exception
and it's just being silently swallowed
now stuff like this is pretty hard to
track down especially in something like
power plant because quite often you
didn't write either the code that's
throwing or the code that's catching
however what we can do with Xcode is we
can pause and then turn on stop on C++
throw and stop on c plus plus cash so
we'll continue go back to appearance
demo and now up sure enough there's the
exception itself and coming from this
function here throw if nil because I
just set it to nil to force exception
power plant tends to not throw
exceptions unless something goes
seriously wrong so that was a simplest
way to do it so let's see where that
actually winds up we'll hit continue and
now we've stopped in the cache or
actually we stopped on the function call
that generated the exception process
next event we step over we'll wind up in
the catch block itself so I also wanted
to show off some debugging of standard
C++ library stuff and C++ standard
standard template library and to do that
I actually wrote my own project because
power plant tends to not use this stuff
which is fair because it was created
before they mostly existed so we have
here is a fairly simple stupid stl oh I
knew I was going to forget that okay
there's a bug
we're in and now I have to you have to
turn off stop on throw in cash when you
before you run the debugger or the
bugger won't run we'll fix that in time
for GM all right let's try that again ok
so here we are actually already stopped
at a breakpoint this is sort of your you
know stl 101 application it sucks sucks
a bunch of words out of the system
dictionary upper cases them and then
blacks out a few to standard output so
we've stopped right here on called for
each I've already got it I've already
got a break point on the function that's
going to uppercase everything using
transform so we'll step into that ok so
here we are stopped in uppercase and you
know we'd like to see the string that
we're operating on so well here it is f
but if we expand it if this is not
really what I had in mind this is not
exactly useful I want to see the string
so this is what custom data for matters
are for you've probably seen already how
you could you can use custom data format
or so pick pieces out of a structure
individual fields but you can also call
a function so what we'll do here is will
say bar dot Easter because standard
library strings have a handy thing that
will return to see string and it's going
to think about that for a minute
really this didn't happen when I was
cracking works great in rehearsal both
worked fine in rehearsal what's going on
here
hmm
well this is entertaining yeah all right
we're just going well while Chris is
doing that will go back to slide and
explain how the custom data for matters
work
the custom data viewers if you've seen
them yesterday Chris let me know when
it's working yep because some data for
matters if you've seen them yesterday
you're a simple functionality that has
three levels of implementation the
simple functionality is there is a
summary column and you can type an
expression into the summary column in
the stand that expression is evaluated
the basic syntax the basic thing you can
do is you can extract members from a
structure or a class and display them in
the summary view and you can put strings
around them so you can say length equals
this member hype equals that member and
that uses this % notation of % member
percent so anywhere you have a struct or
a class or an array you can use the %
notation and get at things inside that
structure and promote them to the
summary of that structure that really
helps you look at a variable without
having to turn down the turn down arrow
especially if it's a very large thing
get you a lot more data density in your
debug review the second level is that
you can evaluate an expression and the
basic rule is that you can put inside
curly brackets in a summary of you
anything that you can type on the GDD
command line and execute and that means
any C or C++ arithmetic expression and
any function call a function calls
within your application method calls on
your objects or system calls to the
carbon framework this is very very
powerful those are evaluated every time
that that variable is displayed so every
step it's going to see if the variables
value has changed and if it has it's
going to re-evaluate that expression so
you got to be a little careful about
this because it's going to be
reevaluated very very frequently so
don't make your expressions too complex
or too lengthy to execute and make sure
you don't call anything with side
effects for example because this is
actually executing in the context of
your application in your applications
process space in your
applications memory space and anything
that this application does can affect
anything this expression does can affect
your application there are a couple of
utility variables that you can use in
this expression dollar sign VAR is the
thing itself the things being the thing
that's being evaluated so you can just
do you know curly brace dollar sign bar
dot and then get at members of it or you
can call methods on that by dollar sign
bar arrow or whatever and then for
convenience dollar sign parent if you're
viewing a class member or a struct
member that dollar sign parent is its
owner so if you're drilling down inside
something but you need reference to a
sibling for example you can do that by
dollar sign parent and then referring
off the sibling or you can get it
information in the parent itself that's
very useful ah the third thing that you
can are you ready um sort of ok if we
can go back to Christmas machine will
show okay so I'll have been able to get
the custom data for matters to work but
I well I will show you is the third
thing which is stepping stepping through
template code so stop here in our own
function and you'll notice that we were
called from for each oh so Chris but
I've got it you Tom remove the custom
data format or I threw in right before
the demo from the custom data for
matters folder and try again you bastard
specific
really folks I was trying to improve the
quality of experience of the demo okay
where is it will show you how to install
custom data for matters library folder
application support apple developer
tools custom data views felis plugin
bundle yeah drag those to the trash
acquitting reopen Xcode and try again I
was up here until five minutes before
the presentation started trying to debug
something that many of you requested
yesterday i want to show you I'll show
you the source code but i'm not going to
show you it working because it crashes
xcode ok so let's try this again so we
stop and transform we want to see the
actual value of this string so let's see
if this works this time vard teaster oh
ah no max Wilson am Maximus Koopa okay
so that's that's all fun so now like I
said we were actually called from for
each so we'd like to see what's going on
up one level so let's move this break
points we don't keep hitting it and if
we just step out mmm template function
and we can just step through this now
again we've got sort of a similar
problem here except this one is even
more complicated I'd like to see the
thing that first points to this is an
iterator and again this is another
obscure structure that has all sorts of
weird bits that i really don't
understand but custom data formats can
deal with these two even though it's a
template type so
star bar uh-huh and there it is so we
can see this changing and getting upper
taste as we step through the loops thank
you and that's it okay back to the slide
please
so we've shown you the two kinds of
custom dataview formulas first the
simple member access and then second the
function call and the function calls are
very powerful they can work within your
application they can work on template
types they can work on C++ classes
they're really powerful but there's one
more thing that's even more powerful so
powerful that'll bring down xcode if you
do it wrong and that's writing a custom
date of you bundle a custom date of you
bundle is as the name implies a bundle
and it's a bundle with really only two
parts to it there's a plist and there's
a dynamically loaded library and the
dynamically loaded library just has
functions that you define and it has one
special static variable okay and the
plist is simply a p list of types type
names as they appear in the debugger and
formulas formulas exactly as you'd enter
them in the custom data view formula in
fact the best way to build one is when
you type your formulas into the debugger
you can experiment with them iteratively
there they're saved automatically be in
a plist in your applications
configuration file you can just go there
open up the plist copy and paste it from
there and put it in your own custom
application specific one and have it
there permanently so the same expression
syntax what you generally do is you
build a small executable a small dynamic
library with a function that you want to
call only when you're debugging not
something you want to build into your
application but something you want to
call only when you're debugging and then
you invoke that from the from the
expression in the plist and though we've
done this to build the carbon and the
foundation for matters which are
pre-built in there put in your library
application support folders and you can
build your own in and put them in your
home directory application support
folders or put them in your machine
specific application support folder if
you want now these library functions as
I said like any other function call
these library functions are
called in the context of your running
application when your application is
stopped at a breakpoint which means
you're in a very very delicate situation
do not allocate memory do not grab a lot
or pend on something else being locked
don't side effect any application
variables don't leak there are a lot of
things you do not want to do when the
debugger has invoked you when your
application is stopped at a breakpoint
so you need to be fairly careful about
writing these when I was writing the the
data viewer to view a error were OS
status I was looking at all the ways to
handle the nineteen hundred different
values and display an intelligible
strings for them and it turned out that
the simplest safest most straightforward
fastest way to do it was with a 1900
taste switch statement and let the
compiler generate the tree to figure out
which string goes with which OS f it
didn't allocate any memory it was very
fast it didn't side effect anything and
it was very safe to use in any context
so buildings for safety in we provide
some functions to help you do this there
are two functions that we provide as
callbacks into the Xcode debugger that
you can use from your custom data view
bundles one just allocates memory that
is associated with that particular line
in the display and you can use that a
scratchpad memory you can put a struct
inside it and put some temporaries in
there or you can use it to build your
string if it's a several step process to
build your string and then when that
variable goes out of scope Xcode will
release that memory so you don't leak
that is much safer than doing malik's
yourself inside your custom data viewer
the second one is essentially an S
printf you can give past this function
this ID and then s printf type arguments
and it will print it to that line and
then free the memory that's used for
that printf afterwards and these are
very powerful so use these callbacks for
the printf function and the buck
allocation don't do anything else except
make safe non side affecting function
calls in your application or access data
members so here's a simple example of
one this is the custom data viewer full
that this is the actual code of the data
viewer for a carbon handle inside the
carbon data viewers package there are
really two parts to this one is the
plist entry and the other is the library
code then the top is the plist entry all
you see it's basically the invocation of
the library code the bundle code with
the variable and the ID and that's all
very straightforward and then the
library code the first two lines are to
get me access to my callbacks there's a
special variable called pbx gdb plug-in
functions that when Xcode debugger loads
my plugin it plugs in a pointer to an
array of callback functions into that
static and then I jump through that in
order to get to my callbacks and then
you see my function the date of viewers
carbon handle expects to get a handle
and the ID it checks to see whether the
handles valid because I don't want to do
anything like jumping through zero if I
don't have to and if it is then I
essentially SPF through this function to
print the size of the handle by calling
get handle size which is usually pretty
safe then I checked the H get state and
mask it against the lock bit and
depending upon the state of that is
printf lock or unlock so this way
whenever I see a handle in my data in my
debugger data viewer I get its size and
its state of whether it's locked or
unlocked and if it's no or the handle is
invalid then I get invalid okay so this
is a very simple data viewer and we have
built in a lot of these for the
foundation classes and we have built in
a lot of these four carbon classes and
if Christians willing to come up again
then he's going to show you some of
these again in appearance sample
which has a little more support for
these things so we're going to bring up
a parent sample in the debugger
and he's going to set a breakpoint and I
think that we figured out proxy dialogue
CP line 106 and I think I'll continue
that's the assert ok that's the assert
we introduced in the first step just
keep continuing ah if you are bugged by
a cert stop it and i'll show you how to
turn this off you have this turned on so
stop right project no go to executables
turn down executables appearing sample
double click scroll down yeah no double
click you were there scroll down break
on calls to debug or debug stir uncheck
that box and that makes your search not
break in the debugger we gave them
something additional unplanned
there you go okay so go find proxy
dialogue CP and go to line 106 should be
a command key to go to a line which is
invalid now for some reason yeah I used
to know what it was well it says its
command l but it doesn't let you do it
right now for some reason yes now it
does focusing front 106 and hey we've
got a break point there great that's all
we need so then go back to the
application and we're going to pull up
window proxy and click the add proxy FS
spec and pick a file any file don't tell
me what it is that's fine it and we
should hit our break point in the
debugger there we go now notice a couple
of things FS the file spec variable the
summary is the name of the file that's
very useful turn down the file spec and
see what you could see otherwise well
there's the V ref num in the parent ID
those are nice but the name its stir 255
and so or just er 64 which is not a stir
255 which we haven't wired up but just
turning it up and seeing just the name
in the file spec that's very nice see
also a is no error just change that to
like negative 39 or something and now it
says US Air so it'll show you what your
errors are like I said it knows all 1900
errors that are in the carbon headers
and that's through a 1900 case which
statement but the next thing that you
know that nav services returns your file
spec in an AE desk well isn't this
interesting look at the file spec desk
and it says it's a type FSS ok so tells
me what types the desk is right at the
top now if I turn it down it'll show me
that it's a type FSS and now
the contents of it it when you turn down
a 80 desk it goes and gets the data out
of the AE desk and then displays it in
that line but it only does that when you
turn it down so it's not expensive
unless you really want to see the
content and it does this with the dollar
sign parent variable I told you about
earlier it goes back to its parent to
get it the descriptor type which is not
in not an OS type it's an int
unfortunately so it doesn't show up as a
four character code but you also see
unused keyword down at the bottom if you
could select that Chris that's an OS
type and instead of showing up as a long
decimal or a hex number it shows up as
four characters in the variable view
that's something we've put four carbon
debugging in Xcode for you okay so
that's custom data viewers if we have a
little time at the end I'll show you how
to construct a data viewer bundle that
crashes Xcode because that's what I've
got to show you right now and we're
working on some better samples for this
to post on the web but what we've
implemented in the carbon dated viewers
is all of the file types alias FF spec
fsr we've implemented the AE desk types
we've implemented inspectors for all of
the opaque a chai toolbox references
window shows you its name and position
menu shows you its title H object shows
you what kind of a chai object is as the
identifier we've implemented basic
supports for the carbon events that
shows you the event class and the event
name for Apple events the same thing the
event class and the event name if it's a
known apple event in the four character
code if it's not and just a whole bunch
of things all the date-time things show
up as date times instead of 64-bit
decimal numbers so I think you'll find
when you're debugging an Xcode you're
familiar carbon data types show up as
the values you think of them as rather
than the value of the GDD thinks of the
mess and I think you'll find that that's
very powerful it back to the slide
please
now I spoke a little about about carbon
events and a little bit about Apple
event now carbon events and Apple events
are large things they're large in their
complex and we couldn't fit them into
single lines in the debugger display
there are some things that you can do
when debugging a carbon application to
see what's happening with your carbon
events and with your Apple events other
than just to see the class and the
particular event type right now they're
accessible only via the gdb style
interface because they scream a lot of
text we're going to try to find a way to
integrate that experience better to do a
little better logging of it but for now
I want to give you some pointers on on
how to do this there's a function called
for carbon events called set event trace
enabled that is once again it's one of
these gdb calls from the from the GDD
command line into the carbon framework
and that gives you exhaustive
information on what carbon events are
happening there's some similar things
that you can do there's environment
variables you can set to turn on and off
apple event debugging and we'll show
those to those are done with environment
variables rather than with the call and
the output of both of these goes to the
standard i/o window which is available
in the console drawer and also available
highly recommended you do this as a
separate window in the xcode environment
as I said for Apple events there are two
environment variables you can set a e
debug sends will print out any event
that you send and AED bud receives will
print out any event that your
application receives there are also some
functions you can call from gdb if you
want to see a full AE desk rather than
just the summary if it happens to be a
custom one of yours GDD print AE desk
will print that desk and if you want to
know more about this we've even put in a
function called the gdb print help
debugging apple event which spool some
help text to standard out and then you
can read that and follow the
instructions in it so let's show you
those
are we still in the parent sample yep we
should remove those great points already
done great and have you set up the eight
debug receives environment variable
partly there it is an environment
variable you can either set up in the
shell before you launch your application
in gdb or you can set it here in the
Xcode API just create it check the box
set the value and then when your
application is launched the shell that
launches that application has that
environment variable set that makes it
very convenient so we're going to run
this application again and the first
thing we're going to do is to throw an
apple event at it and my favorite way to
throw apple event that an application is
by using apple script i'm going to show
the run logs first we get to see what
shows up clean Christine empty run log
now chris has written a simple
applescript here I'm sure you had to hit
the books to learn how to do this and
he's going to run the script and he's
going to send
hmm the theater we expected but we're
not the area's expected the absence of
the run log is not now not underscore I
did turn the phone
running against the debug version
we didn't in rehearsal that's true
all right fine I'll try that suggestion
fine we'll show you the carbon steel or
that
he was going to turn on AE debug just to
make sure
show the run line and the apple event
and still no joy I can't tell you what I
broke this time but it's obviously not
your fault it worked in rehearsal it
worked in rehearsal all right okay well
there it is is that oh no it's there
it's just not in the run oh it's not in
the run log chrisitan standard i/o show
show ftdi Oh bear it okay my mistake we
were looking in the wrong place it was
there all the time so here are all the
multiple events that Chris was sending
to the applications and when he turned
on AE debugging it gives you even more
information for what handler what
handlers it's looking for what tables
it's looking for the handlers in and
what in order it's looking for them in
so if your Apple event handlers are
firing in an unexpected order or though
the wrong ones are firing turn on a
debug one in your environment variables
and this information is logged to the
output this is very useful if you've got
a scriptable application and figuring
out what applescript sends you or what
other applications send you in terms of
events and once again it comes up in the
standard aio log just like it says on
our sheet right here not in the run log
another thing that comes up in the
standard i/o log is the carbon debugging
carbon events debugging spew so what
Chris is doing now in the little gdb
terminal window is he's calling set
event trace enabled it's just parent
Aaron but I know it's not it's not you
tested it okay we'll talk about that
later so now that he set the event
tracing enabled when we go back to the
application and start doing things that
caused carbon events to get sent we see
a large amount of diagnostic information
about what carbon events are being sent
to whom and when with what arguments
who's handling them and what happens as
a result of it sending event called
handler event was handled leaving target
send event to event target entered it is
more information than you probably need
but if you are trying to debug your
carbon events this is the first tool to
use because it shows you explicitly step
by step everything that is happening
okay and I think that that's all for the
demos now I know you say but I like Max
bug well it's a transitional experience
but I think that you'll find many of the
things that you want to do the inside
max bugs our presence in GDB Quinn wrote
a great techno 10 20 30 g DD for max bug
veterans which really helps you
transition from one tool to another gdb
is not as quick it does not run down at
the chip level it doesn't take over the
machine and so you have these process
lags it loads all the symbol files
because it's a symbolic low-level
debugger not just a machine low-level
debugger so you know you won't get the
snappy response time from gdb that you
expected with max bug gdb by its base
nature is not carbon savvy it doesn't
have all the things built into it we're
layering things on top of it to make it
more carbon savvy and gbb doesn't
necessarily show you the whole machine
because it only attaches to a given
running process at a time but gdb is
much better at symbolic much better at
what types of variables are it has not
just better conditional break points but
it has future breakpoints you can set a
breakpoint in a library that hasn't been
loaded yet and when that library is
loaded the breakpoint will be set in it
automatically that's very useful to use
gdb is better at evaluating expressions
and calling functions and it's better at
not crashing the machine if you do
something wrong in the debugger mainly
because it's running in a different
process than the application is but I
hear you say but I like codewarrior IDE
debugging well this is a lot more valid
because
codewarrior ide has a lot more windows
that do useful and interesting things
interestingly enough when you're
debugging mocco on with codewarrior it's
using GV be for a lot of the underlying
machinery to step and to control the
execution flow of the application though
it's using its own functions to get the
symbolic information and to display the
variables and stack traces now these
debugging entry points are available
from codewarrior expressions too so all
the things that we've showed you from
the gdb command line those are available
from the Code warrior ID debugger as
well if you happen to be using that and
if you like tone Ranger for memory
Diagnostics tool well you know zone
Ranger really is great for debugging
heap zones and heap tones are just not
that relevant in Mac OS 10 anymore you
in order to really understand what's
going on ian mac OS 10 memory management
it's less of a static looking at what's
happening in my heap zone and more of a
dynamic looking at who's calling malik
and when and are these things getting
released in time and by whom and on what
threads and some of the mac OS tools
like Malik debug and like samplers
memory allocation viewer those are much
much more relevant to debugging Mac OS
10 memory problems than static views of
your heap like zone ranger and is my
heap the fragmented or has my heap been
stepped on our memory Diagnostics with
carbanion a new pointer a new handle
just get down and call malloc so if you
debug with Malik you're debugging new
pointer a new handle that's really the
important thing to remember your handles
are just not going to move around so
this whole class of problems that you
used to do on Mac OS 9 they just don't
exist anymore on 10 your low-level
memory handling code is not going to be
called because on until you hit that
four gig barrier and on a g5 not even
then you're not going to be asked to
compact your heap it's just not going to
happen your big problem will be leaks
scribbling on your own allocations
you'll get
the wrong pointer somewhere and trying
to use something after you freed it and
those are things that the mallet debug
tools and the sampler tools are really
good at doing so let's summarize we've
gone through a lot of stuff on carbon
debugging you've seen the C and C++
exception handling the throw and break
on throw and break on catch you've seen
stepping through templates and using
custom data views in order to see the
contents of templates which is very
useful you've seen some built in carbon
and foundation data viewers that show
you your carbon data types in a very
familiar way you've seen how to build
your own either within a simple member
access or with a complex expression or
even with a bundle of code that you
write yourself and drop in to do your
own custom data viewers we hope that
you'll be able to use some of these
tools in debugging your carbon
applications we will be down in the van
ness room to help you get up on xcode
and get your projects on xcode so you
can take advantage of some of these
tools will be there for the rest of the
day and we're going to bring up God
four-digit code we've got actually a lot
more to talk about before I call up
Godfrey because I've got 18 minutes and
I'm not going to let you be bored we've
got a lot in Xcode right now in the
developer release in the one point 0 the
features you've seen are going to be
polished and they're not going to crash
and they're going to be a little more
robust that's what 1 point 0 is about we
know what you need we need we know you
need a more flexible type viewing system
we get very spoiled by using the code
warrior view anything as any type system
and by the code warrior memory viewer
that's our aim we're working on it it
won't be into one point oh but it should
be in the next release after that that's
certainly on our list getting these
tracing tools to debug more voluminous
things getting them built into the IDE
so you don't have to spool them out to
another text window and then scroll
through it that's another priority we're
going to work on that to find a better
integration of those tools of course you
we can never step or view too quickly
we've got the problem
now of the more data you want to see the
slower you steppin so there's a tipping
point there between fidelity of data and
speed of stepping one of the things you
can do is you can turn off custom data
views while you're stepping and then
turn it on again in order to look at the
values now that we found is a useful
compromise and then watch points and
event points we know those are very
important to you we're working on those
you can do those at the low level GDD
command line we're working on bringing
them up into the IDE interface there are
a lot of resources you can use for more
information on this Godfrey is your main
contact and the development tools
engineering feedback as we've told you
all week exco dash feedback at group
apple com use bug reporter to post bugs
one point o is only going to be as good
as the bud reports we get and we'll be
talking about these on mailing lists the
public information now and
non-disclosure information should really
come to the Xcode list there are a
couple more sessions there's a section
that's right after this one called
software testing tools for mac OS 10
which will go into more more into how to
do use automated testing tools both
apple and third-party to do automated
testing of your applications and
especially your applications you i know
that's a very important issue for a lot
of you if you are bringing your carbon
after Mac os10 you really really have to
go to how to write a modern carbon
application session at two o'clock today
in the nob hill room if you're still
using mbar resources and you're not
using carbon events and you still have
whole big hunks of code that does memory
management in your application you
really have to come see that a carbon
application on Mac OS 10 is different
than a carbon application on Mac OS 9
there are a whole lot of things you are
freed from a whole lot of new
capabilities that you can use and please
come to the ADC feedback forum today if
you're not going to they have the right
of a modern carbon app session and give
a DC some feedback on the information
that ABC has been providing to you the
reference library go to the CD set and
see the presentation
last night on basic debugging to go deep
into the generic debugging capabilities
of gdb go to the debugger services
reference in the carbon performance
directory a lot of information on
debugging with GDB GDB internals the gdb
release notes are always very helpful
Quinn's tech note is very helpful and
here's the carbon tips and tricks
document it's a developer apple com
developer apple com / carbon / tips and
tricks HTML it's a very long document
with a lot of things including all of
those ap is the names we called to print
out diagnostics from the carbon frame
works very very useful technical note if
you haven't used it before the chug
toolkit is an incredibly useful set of
tools for doing machine level
instruction level debugging of what your
performance profile of your application
is there were been a couple of demos so
far this week and you can go back to the
DVD set and watch those or on your
developer tools CD open up the chudd
tools package and install them and just
see what miracles they can show you in
your code
you