Carola Nitz - Advanced Debugging Techniques your senior hasn’t told you about

[Music] yeah hi everyone I'm Caro a senior software engineer at a company called video lapse we're a consulting company behind VLC and I'm gonna talk about debugging things your senior hasn't told you about yet so why am I talking about this topic well as it turns out 50% of our time is spent with either fixing bugs or making code work and according to this random chart that I found on the Internet this amounts to 312 billion spent per year for the entire global software industry that's quite a lot so why are we actually spending that much time on debugging so what are the problems that we face well for one we sometimes don't have enough information in this case I am somewhere in uikit and I'm stuck there I don't know how I got in there and what part of my code cost this issue second we have time-consuming tasks that we do over and over again in this case I tried to print the frame variable on a uiview but it told me hey I cannot find the frame on your object of uiview and I'm like well but it definitely exists on there and then I remember oh I got to import UIKit and then I actually get the data that I want to and third sometimes we simply don't know about good practices so I will tell you a little bit about defensive programming and how to use the third sub precondition so what are the coverage topics I'm going to tell you how you can get more information when you need to fix a bug or a problem then I'm going to go up go about how you can speed up your day-to-day debugging and last but not least about best practices for error handling and debugging so let's start with with an example that I encountered earlier this year I was working on the TV OSF and I had an unresponsive UI I could't scroll I couldn't click images wouldn't load and when I stopped the program what I saw was this my memory spiked up and there were lots of objects being allocated and when I looked at the stack trace I saw that I was somewhere stuck in uikit so now you wonder what did I do so here's what I did I was realizing okay stackoverflow can't help me at this point but after doing this for a little bit I remembered oh there's this one command and I'll Adibi that I could use for this elodie be to the rescue and I used register read register read helps you to print out the general-purpose registers and I'm not sure if you can see this in the back but in register 10 I have a reference to the VLC network image view that was enough information for me at this point to find the evil line via brute force and to comment it out and then to fix my problem so I was a happy developer my program worked but just about a month ago I found out that there is another way Tyla Fox was actually tweeting about this wonderful underappreciated debugging tool on UIKit which is the layout feedback loop debugger the layout feedback loop debugger is a launch argument and for those of you who don't know what a launch argument is I'm going to show you how you can actually enable them so when you go on edit your scheme there is a tab called arguments and there you can edit a number of launch arguments and underneath it there are also environment variables that you can add Apple has been so nice to give you already a couple of them in the options tab like the non localized strings for example is a launch argument as well as the system language and the application region if you enable for example the non localized strengths you will see in caps lock and your app where you didn't localize a string if you change the region it will for example say that you're on Cupertino even though you're in Berlin so you can test your app in those different regions obviously not every of those launch arguments is listed in here under the diagnostic tab you find a couple of the environment variables so you can enable for example malloc scribble which will tell you what kind of objects are allocated and so many more so let's go over a couple of the launch arguments that you can also have I'm going to talk about the UI view layout debugger the concurrency debug for core data migration debug and SQL debug and anis trace events so first up the layout feedback loop debugger so this is a large argument that where you can set a threshold and the threshold can be a value between 50 and a thousand and accounts the number of views that run layout sub views once you hit that value it will hit an exception and it will dump info into a lock and if you don't like to look at locks you can just stop there and then you can print the layout feedback loop debugger on the UI view layout feed loop debugger if I know this is a lot and if you want to actually learn more about this there's this great talk from 2016 what's new in Auto layout by Marianne Goldeen and she's talking 50 minutes about how you can actually analyze those locks what you need to look for and it's an incredible great talk ok but this is great for Auto layout issues and about UI debugging but what about for example core data it's widely used but it's not always easy to debug when things go wrong so here's the launch argument that will help you with concurrency if you turn concurrency debug on you will see an LED be a little message that lets you know hey core data multi-threading assertions are enabled and when you use your app this will crash our it will stop when you try to access an object context or manage object from the wrong dispatch queue a little fun fact about this Apple decided with iOS 6 oh it might be a great idea to turn this on by default well a lot of apps started to crash and Apple soon decided ah maybe this wasn't the greatest idea so yeah if you run into this you will see this wonderful all that is left dishonor and if you want to learn a little bit more about how you can resolve these issues and why they are happening there is a great blog post but Ola Begum on from 2014 that will tell you it can resolve these ok the next one is migration debug and SQL debug so if you turn on migration debug and you're doing a core data migration this will log information about exceptional cases when it migrates data you will get hash values and you can then look at them if you have there's a program where you can actually see the objects in your database and the next one SQL debug you might wonder why there is a three all the other launch arguments you normally toggle on and off in this case this is a value that determines the verbosity of the locks so 3 is the highest value and it will give you a lot of locks and you can see what is actually happening under the hood you see all the SQL statements and yeah see what it actually is being done and something that I found out while I was researching this topic was you can actually also pass in lock launch arguments at runtime so in this case I was passing it into the TextEdit and I turned on and it's trace events and when I was hovering the mouse of the text editor it would print all of the events that it was receiving and that was super interesting for me to see I didn't know about this actually before I was preparing this talk so there are lots of hidden launch arguments and environment variables and these are just some examples if you want to find out more about them and how you can for example visualize constraints or lock more info about objects I would definitely recommend those to tech notes by Apple one is the iOS two bugging one and the other one is the Mac OS debugging magic talk and there are also tools listed and it's it's an old document but there's still so much valuable information in there ok so this is great if you have a certain buck or problem that you need more information about but what if you just try to make things work and need to inspect jects so let's go over some typical time-consuming tasks and how you can save time here so first up I like to show you an easier way how you can inspect private properties without having to subclass with Swift for we introduced key paths and you can easily use that to observe changes in this case I observed the background color and I can lock the changes of the old value and the new value and not before I was just sub classing it I would replace everywhere at the type of the class and I would overwrite for example set frame and then when I needed to when I found out what was going wrong I had to revert all of this so this is an easier and faster way to do this next up the property that was not found on your application a short raise of hands who has ever encountered this issue ok everybody so I'm not sure everybody knows when that actually happens we have two contacts when we're departing one is the objective-c one and the other one is the Swift one objective sees actually chosen by default so what we have to do is we have to actually tell it hey the object that I'm handing you that's actually a Swift object so this was something that I was doing when I was first starting with Swift and that's obviously not the easiest way and it's very tedious if you have to do this all the time so then I found out oh you can just import UIKit our foundation and then I don't need to do this anymore this also by the way removes the need to arm casts trucks in a lot of places but that's also really tedious so the next step that you can take us you can create a breakpoint on your application main and you just add a debugger command to import your eye kit and import foundation you check the checkbox that it should automatically continue after evaluation I think sheesh stuff wrote a blog post about this that's already great but there's even something more that you can do because right now this is only available my project right but I might have multiple projects so what you can do with this is you can move that to use a break point and if you want to be nice to your colleagues you can even make that a share break point so this obviously saves you a lot of time already so I was wondering are there more like this and then I found the Ennis kvo deallocate break point so this will break in places where you still have observers around and should have removed them you know sometimes you will crash later on when a message is being sent to this object but this will actually alert you early on that you should have now removed that observer and next one up is you can actually add it your exception breakpoint to print out argument one you wonder for this argument one well that's actually the exception and before I always have to press continue continue continue until finally it will show up at my locks this will immediately print this so these were just three examples of useful use of break points and if you want to learn more about this PS PDF kit had a great blog post about this where they have so many more use of break points and they've added to it over the over the last months and they also link to an article that will teach you how you can script break points which can be very interesting so this is great these break points say first time while we're making things work and the KBO break point alerts us about a bad state early on but we sometimes know already about cases where we entered a bad state and how can we make life for a fellow programmers easier in this case so let's talk about your practices for error handling and how we can save time here so the first thing that might come to mind are assertions in particular assert and assertion failure so what are assertions there are runtime checks to catch program our early programmer errors early on so they ensure that certain conditions are met and if not your app will terminate early on so here's an example for this we're checking in the condition if a string is no and if not [Music] we're gonna break there we have the message in mail a parameter and what is interesting about this is we have a message that we can actually forward to the user and can tell them hey this is by the way what is going wrong and you can see in the next line here this was would crash because the string is force unwrapped and the message parameter is actually the interesting part because you can educate your users how to use a function or how you should use your API and it might come become a little bit clearer in the next example for assertion failure here we can use this to actually guard against code paths that shouldn't be executed here for example I have cells that are being created and in the default case I'm just saying hey you have a new cell type that you might want to add to the cases and further down there's something that is even more helpful I tell whoever is using this part of the code that the cell is no but not only that the cell is no I'm actually telling him hey did you forget to register the identifier so not only do I tell him what went wrong but I can also give the user hints about what he can do to fix this issue something to note about assertions is that they're only turned on in debug mode so what determines actually if we're in the buck mode so that's the Swift optimization level and we have three levels here we've got the debug one which is owned um we've got the release world which is - oh and then we've got uncheck release the unchecked release one will give you blazing performance but it does that by removing a lots of error checks if you do this for example you wouldn't get the array out of bounds check you wouldn't get the unwrapping nil one so in the worst case scenario this will lead to memory corruption so you really shouldn't do that unless you really really know what you're doing so as we found out assertions are only enabled in debug mode but what if you need to guard against the bad state and a release bolt so for this we've got precondition and fatal error this is for condition where it would be too dangerous to continue because you might for example corrupt data precondition and fatal error precondition failure and fatal error are by the way also enabled in the unchecked releases so let's look at an example from the Swift library here we've got the repeated value function and this lets you create a collection with the same value repeatedly and that depends on the count the precondition here is catching that the count is a number that is bigger than the zero and we actually tell the user them oh that count should not should be non-negative if we would have a negative value later on we would crash so that's better to exit early on here next example is for fatal error this is actually in the an estate format a class which uses an underlying CC library the ICU which is the international components for Unicode library and as you can see in the guard statement here we have a fatal error which happens when were unable to talk to the ICU this is an unrecoverable system state that we want to avoid and it doesn't make sense to to go on with the program at this point so we're crashing here and something that I found out when I was like looking at fail era was apparently some developers are using this to detect if they're running on a jailbroken device and then they use fatal errors so that people can for example not cheat in their games found that very interesting so let's recap we saw assertions are enabled in debug we saw that those are not enabled and release but precondition precondition failure fail error are and in the unchecked release we still have precondition failure and fatal error so what did we learn about today well we learned that we can use read register and launch arguments to get more information when we're trying to fixed box we learn that we can use key paths and user breakpoints to save time when we're trying to make things work and last but not least we learned about assertions preconditions and fatal error to educate our fellow developers users how to use our api's and these were some of my resources there were great talks and blog posts about assertions these are obviously additionally to the ones that are already mentioned and yeah that's it thank you [Applause] you

Channel: Swiss Mobile Developers Association

Views: 2,281

Keywords:

Id: LbAlIzxSO6M

Length: 18min 31sec (1111 seconds)

Published: Mon Apr 23 2018