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