WWDC2003 Session 308

Transcript

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