Transcript
>> Hi everyone.
Hi, and welcome to finding bugs
using Xcode Runtime tools.
My name is Kuba, I am an
engineer on the program, another
system inside developer tools.
And today we will be talking
about finding bugs at the
program runtime and the tools
for that.
So, let's jump in.
Xcode already has several ways
of telling you that you have
some bug in your program.
For example, with compiler
errors.
Compiler warnings.
Analyzer warnings.
Or test failures.
Last year in Xcode 8 we have
added a whole new category
called Runtime Issues.
Those issues are found at the
program runtime by several
different tools.
When you run and debug your
applications as you are used to,
these tools find and detect bugs
at runtime and they display them
in the Runtime Issues Navigator
in Xcode.
If you are not actively watching
this navigator, Xcode also
indicates that it found some
runtime issue by showing this
purple warning icon.
You can click any of these
issues in the Navigator and the
editor will tell you which line
of code contains the bug.
The source of this bug can vary
because different tools report
different types of bugs but all
these tools that we're going to
talk today in this session, you
can find in the diagnostic step
in the scheme editor.
And in Xcode 9, it now contains
some new features.
So, you'll see that it now has
address sanitizer, threat
sanitizer, undefined behavior
sanitizer and also main thread
checker.
So, these tools, which all find
bugs at program runtime, are
what we're going to talk today
in this session.
So, first I will introduce main
thread checker, a completely new
tool in Xcode 9.
Then I will talk about address
sanitizer and thread sanitizer
and the improvement that we have
made to these tools this year.
We will introduce another
completely new tool, undefined
behavior sanitizer.
And finally we will provide tips
and best practices, how you
should be using those tools
effectively.
So, let's jump in.
The main thread checker is a
completely new tool in Xcode 9
and it detects violations of
some commonly used APIs.
And specifically it focuses on
UI updates and multithreading.
Some APIs require that you only
use them from the main thread.
For example, that's the case for
many APIs from the AppKit and
UIKit frameworks.
And they are used by most
graphical macOS and iOS
applications.
And I assume that if you are
using those frameworks, you
already know about this
restriction that you have to
call those APIs from the main
thread.
And that's easy to do.
We just make sure that we will
call those APIs on the main
thread only.
But there are tasks that you
don't want to be executed on the
main thread, like file downloads
where you need to wait for some
data or image processing, which
usually involves some, like,
heavy computations.
So, these tasks need to be moved
off the main thread so that the
UI is still responsive and your
user interaction is not blocked
in your app.
However, these tasks also need
to trigger UI updates.
And if those UI updates involve
calling AppKit or UI kit APIs,
that update needs to happen from
the main thread.
And it's very easy to make a
mistake, to accidently call this
UI update from the wrong thread.
And it can have serious
consequences such as missed UI
updates where the UI just does
not update at all or other
visual defects.
But even more serious things
like data corruptions or
crashes.
So, to avoid this problem we
need to make sure that this UI
update only happens from the
main thread.
So, with that, I'd like to
introduce Main Thread Checker
and show it to you right now.
So, what I have here is a very
simple application which
downloads some data from the
internet.
It's actually downloading a file
from this long URL which is
present on the
developer.apple.com website.
It's some sample code that Apple
has published in 2013.
And it's a zip file.
It's several megabytes large and
it will serve as an example file
if you want to download.
To download this file, I'm using
a class called URLSession that's
provided by Foundation and it's
a very convenient way of
downloading files.
The UI of my application is very
simple.
Let's take a look.
It contains a single button and
a progress bar.
So, I have actually implemented
the progress callback of
URLSession.
And from this callback I am
updating the value on this
progress bar.
So, let's run the application
and see if it shows the progress
of the download as it's supposed
to.
Let me now click the button to
start the download.
And you might see that
something's not quite right,
because the progress bar is just
stuck at the beginning.
And now it has for some reason
jumped straight to the end.
So, now I might be wondering
that there's some bug in my
application or URLSession may
not be working correctly.
So, the best thing about this
feature is that I don't need to
guess what wrong - Xcode has
already found the problem.
If we take a look back into
Xcode, we'll see that it's
informing us that it has found a
Runtime issue.
Let me click this Runtime issue
to get some details, and you'll
see that the navigator has now
switched to the Runtime Issues
navigator.
And it's informing me that I'm
calling some UI API from a
background thread.
I'll click this issue to go to
the code which contains the
invalid API code.
And in this case we can see that
we are actually setting a new
value on the progress indicator
from a background thread and
that has to be done only from
the main thread.
So, that's a bit unexpected
because I'm not trying to run
this code on a background
thread.
I'm actually not doing any
threading in my code at all.
So, the real problem is that I
actually made a mistake when I
was grading my URLSession class,
sorry, object.
On this line, where I'm creating
the URLSession, I'm supposed to
specify which view should be
used for the callbacks for both
the progress and download
finished callback.
Instead of providing a queue, I
just said nil.
That means I don't care.
And URLSession will probably
involve those callbacks from a
background queue.
So, now we know why these
callbacks are called from a
background thread.
To fix this, I could either use
GCD and dispatch the UIUpdates
back to the main thread.
Or in this simple case I could
just ask URLSession to directly
call my callbacks on the main
queue.
So, let's do that instead.
I'll just ask it to call my
callbacks on the main queue and
let's run the application one
more time to see if that fixed
our problem.
If I click the button this time,
we'll see that the progress bar
now animates smoothly and it
indicates the progress of our
download.
[ Applause ]
Sorry, I need to switch back to
my slide.
There we go.
So, we've seen an example of how
Main Thread Checker helps us
find and fix a bug where we're
calling some API from the wrong
thread.
Notice, that I didn't need to
turn these two on because it's
actually enabled by default
whenever you are using the Xcode
debugger.
But if you want to find this
code in Xcode, you'll see that
it's available in the diagnostic
step again and you'll notice
that now in Xcode 9 we have this
checkbox called Main Thread
Checker.
So, this is the place where you
can turn the two on or off.
If you want to make the debugger
stop on a violation of this
rule, you can use the pause on
issues checkbox and with that,
the debugger will stop when it
detects an issue and you can
inspect your current program
state and to figure out what
went wrong.
Now, let's talk about some
common mistakes that leap to the
bugs that Main Thread Checker
detects.
So, as you saw in the demo,
networking callbacks is one
place where we, is a place which
often happens from the main
threads, sorry, from the
background thread.
So, you need to be careful and
you need to dispatch your
UIUpdates back to the main
threads.
Another common place for
mistakes is when you are
creating and destroying NSView
or UIView objects.
This also needs to happen only
from the main thread.
If you are writing libraries or
frameworks and you are providing
some asynchronous API.
You should be very careful when
designing those APIs.
Let's take a look.
Let's say that we want to have
an API that performs some long
and heavy computation.
So, it does that in an
asynchronous fashion.
Here the caller of the API needs
to provide a closure to the API
and the closure will be used as
a completion handler.
So, when the task is completed,
you, the API will call the
provided closure.
However, in this code sample,
it's not obvious which queue or
thread will be used for this
closure.
And it can easily lead to a
mistake where some code is
executed from the wrong thread.
Good APIs let or even force
their users to specify which
view should be used for the
completion handle.
So, if you read this code
example, it's obvious that the
closure will be called on the
provided queue and you don't
even need to read the
documentation for the API to
learn that.
So, as I said, Main Thread
Checker detects violations of
API threading rules.
It supports AppKit, UIKit and
WebKit which are three very
commonly used frameworks and
they all have the same main
thread only requirement on a lot
of their APIs.
The tool supports both Swift and
C languages.
And in contrast to the other
tools that we are going to talk
about today, it does not require
recompilation.
So, you can even use it on
existing binaries.
The best part is that is
actually enabled by default.
So, you don't need to do
anything to start getting these
warnings from the tool.
It's actually enabled whenever
you're using the Xcode debugger.
So, that was Main Thread
Checker, a completely new tool
in Xcode 9.
[ Applause ]
Now let's talk about another
large source of problems -
memory issues.
And let's talk about Address
Sanitizer, which finds those
issues.
Address Sanitizer has been
introduced in Xcode 7, two years
ago.
And it's proven to be a great
tool because it finds
security-critical issues.
For example, use after free bugs
and buffer overflows.
It's also very helpful when
trying to diagnose hard to
reproduce crashes.
Because it often makes those
crashes deterministic and it
finds memory corruptions when
they actually happen and not
some time later when the
corruption affects some
unrelated code.
If you'd like to know about how
this tool works and which exact
bugs can it find, I recommend
that you watch a WWDC from two
years ago called advanced
debugging and Address Sanitizer.
In that session, we have
introduced the tool and we have
also talked about how it works
under the hood.
Address Sanitizer is also
integrated into Xcode UI and
into Debugger.
Let's take a look.
If you want to use Address
Sanitizer, all you have to do is
again go to the scheme editor
and you'll find that there's a
checkbox called Address
Sanitizer which can be used to
enable this tool.
In Xcode 9 we have added another
checkbox that turns on an
optional check of use of stack
after return, and I will
describe this feature later.
But you can also notice that we
have now added compatibility
with Malloc Scribble.
So, you can enable both of these
tools at the same time.
You can then run and debug your
application as you are used to.
And if your program doesn't have
any memory issues and if it's
not touching any memory that
it's not supposed to, then good.
Address Sanitizer will not
interrupt your work flow.
But if it finds a problem, it
will stop the program and it
will describe what the issue is.
So, in this case we are
accidently using some
deallocated memory.
And that's a serious bug.
And when Address Sanitizer finds
this bug, it will also display
some additional information
about that memory that we're
accessing.
And we'll get not just its
address but we'll also get some
description of it.
How large the heap region is and
which byte out of it are we
accessing.
And we also get the allocation
and deallocation backtrace of
how that memory was allocated.
So, this is super useful
information when you're dealing
with use after free bugs,
because this really helps to
diagnose them, right?
So, we've seen what Address
Sanitizer is but now let's talk
about some new features that we
have added this year.
It now detects two new classes
of bugs.
Use after scope and use after
return.
And it's also now compatible
with Malloc Scribble.
Let's take a look at some
examples.
In this code sample, let's say
we have a variable that is
defined inside the body of an if
statement.
We take a pointer to this
variable and then later outside
that if statement, we are using
that pointer to save a new
value.
So, this is any value because we
are, the pointer is no longer
valid here.
And address sanitizer is now
able to detect and describe the
issue for you.
Another type of bug happens when
you're returning, when you're
using a pointer out, after
returning from a function.
So, in this case the function
returns a pointer to its local
variable which means that once
the function returns, that
pointer is no longer valid.
And if we try to use it, we are
again accessing garbage memory
and the Address Sanitizer is
able to detect that and describe
that issue for you.
However, this check is not
enabled by default and because
it has some extra overhead and
you have to opt into it.
To do so, you can use that extra
checkbox in the scheme editor
that I mentioned and showed
earlier.
Now, if your projects are
written in Swift, you might be
wondering why should I care
about Address Sanitizer?
Swift is a much safer language
but the reality is that a lot of
projects are still mixed and
they have bugs written in C and
Objective C.
And for those parts that are
written in C and Objective C,
address sanitizer is still a
very effective tool and it will
find memory issues in that, in
these parts of your project.
Some of you might also be using
unsafe pointer types which, as
their name suggests, are not
memory safe and you have to be
careful when using those.
So, let's take code as an
example.
In this code, I have a string,
Hello, World.
And I am trying to convert it
into a C-style string using
unsafe windows.
So what I'll do is that I will
call this API called with C
string and it will create an
unsafe pointer for me.
And this will provide this
unsafe pointer to me in this
closure that I am passing
through it.
If I store this pointer outside
of the closure, I am violating
the rules of the C string.
And that means that when I try
to use this leak unsafe pointer
later, I am again accessing
invalid memory.
And Address Sanitizer is able to
detect invalid uses of unsafe
pointers like this, even in
Swift code.
To fix this, we need to make
sure that we only use that
provided unsafe pointer within
the closure that we are passing
with C string.
So, if we move the code into the
closure like this, that fixes
the problem.
And in this case, we can
simplify the code even further
and just remove that local
variable completely.
It is generally a good idea
never to store unsafe pointers
into local variables or
properties.
So, if you are using unsafe
pointers in your Swift projects,
I definitely will recommend that
you turn Address Sanitizer on in
your projects just to make sure
that you are not accidently
using unsafe pointers wrong.
So we've seen how Address
Sanitizer helps you find and fix
bugs.
But it can also be a very
helpful tool for general
debugging as well.
Because have, if you, when you
are debugging your projects,
have you ever wondered where was
this memory allocated?
Well, I have some good news for
you.
If you are running with Address
Sanitizer, it's actually enabled
to tell you the allocation
backtraces of any memory that
you ask it.
And it can also provide the
deallocation backtraces for
memory that's already
deallocated.
And furthermore, it can show you
which bytes of memory are valid
and invalid.
So, let's take a look.
This time we are not
investigating a crash.
This is just a regular debugging
session where I'm stepping over
the lines in a function.
I can control click any variable
in the variable view.
And if that variable is a
pointer, I can select view
memory of.
Normally this would just give me
the view of, into the bytes of
that memory object.
But if you are running with
Address Sanitizer enabled, you
can expand the memory item in
that navigator and it will
display the allocation and
deallocation backtrace for that
memory.
You can also notice that some of
the bytes in this memory view
are grey and some are displayed
in black.
The greyed-out bytes indicate
invalid memory and, or as we
say, poisoned memory.
Which means that your
application must not be
accessing those bytes and if it
does so, that is a bug.
And Address Sanitizer will find
it and detect it.
You can also access the
information about the allocation
and deallocation of memory
objects in the [inaudible] text
console.
We can use this command called
memory history and pass it any
expression that evaluates to a
pointer.
So, let's use the pointer value
directly in this example and the
text console will print out to
allocation and deallocation
backtraces in text output.
So, I hope that I have convinced
you that Address Sanitizer is
great tool and that it's useful
for both C languages and also
Swift.
And that it helps with memory
corruptions and crashes.
But also that it's a very useful
tool for general debugging as
well.
But now let's talk, let's take a
look at another large source of
crashes and mysterious memory
corruptions, which is
multithreading.
And let's talk about Thread
Sanitizer which detects those
issues.
So, as I said, Thread Sanitizer
is able to find multithreading
issues.
For example, data races.
However, these issues,
multithreading issues, are
usually very sensitive to
timing.
Which means that they are very
hard to reproduce.
So, Thread Sanitizer is not only
able to find races where the two
memory accesses actually
collide, but it can also find
races that did not manifest
during that particular program
run.
Even if the racing memory
accesses happened at different
times but there's no
synchronization between them,
that is still a race.
And Thread Sanitizer is able to
find it.
That's because the next time you
run your application, the timing
will be different and it might
be just right to trigger a
memory corruption.
So, Thread Sanitizer is able to
find races even when they do not
manifest.
The tool works on 64-bit macOS
and 64-bit simulators.
And if you want to learn more
about the underlying technology,
I recommend that you watch a
WWDC from last year called
Thread Sanitizer and static
analysis.
So, I mentioned data races.
But let's see what they are.
Any shared data, any mutable
data that is shared between
multiple threads needs access
synchronization.
If you are missing
synchronization on your shared
mutable variables, that means
you have data races.
And data races are undefined
behavior.
And in presence of data races,
our programs can have memory
corruptions and crashes and all
of these problems apply to C
languages but also to SWF code
as well.
So, let's take a look at an
example in Swift.
So, in this case we have a class
called event log which just has
a simple function called log
that prints out some text
message to the output.
But it also tracks which was the
last event source that called
that log.
And it saves that information
into a stored property called
last event stores which is an
optional and at the beginning
it's nil but as soon as someone
calls log, it will be perfectly
will be populated with that
particular log source.
And now let's say that we have
two threads which are both
trying to call that log at the
same time.
Let's say that thread one is our
networking subsystem and it's
logging that some download has
finished.
While the second thread, which
represents our database
subsystem, is logging that query
is completed.
That is a data race.
Because we're accessing the same
memory location at the same
time.
And Thread Sanitizer will warn
about this.
So, to fix this we need to
introduce synchronization.
And the easiest way to do that
is by using a serial dispatch
queue.
Now, because this queue is
serial, it will only execute one
work item at a time.
So, if we wrap the body of the
log function into queue.asynch,
this will provide the correct
synchronization.
And note that I am using asynch
here because we don't need to
wait for the result of this
function to complete.
Because this function does not
provide any results so it
doesn't make sense to wait for
it.
So, this not only fixes that
race but it also improves
[inaudible] because now whoever
calls log will no longer need to
wait for this printing to
finish.
And this way this whole class is
now thread safe and we can use,
we can call log from multiple
threads.
Dispatch queues, which are
provided by Grand Central
Dispatch or GCD for short, are
readily available in Swift and
they should be your first choice
of synchronization.
Even though there's other
mechanisms of providing
synchronization, GCD is very
lightweight and it's very easy
to use from Swift.
A good idea is to associate your
data with serial dispatch
queues.
And only accessing the data from
those queues, which will
guarantee that you're only using
your data in a synchronized way.
And if you'd like to learn more
about how to use concurrency
with GCD, I recommend that you
watch another WWDC from last
year called concurrent
programming with GCD and Swift
3.
But now let's take a look at
some new features that we have
added to Thread Sanitizer in
Xcode 9.
It's now able to detect races on
collections and also a whole new
class of bugs that is specific
to Swift code.
Previously Thread Sanitizer was
only able to find races on the
raw memory accesses like we saw
in the previous example where we
were just directly accessing
some stored property.
But synchronization is often
needed even for larger data
structures.
For example, collections.
Consider this code example where
in Objective C we are using an
instance of an NS mutable
dictionary.
And two threads are using the
same instance.
Let's say thread one is looking
up a value in the dictionary
while the second thread is
trying to write into it.
So, it is a problem and newly in
Xcode 9 we are now able to
detect this race.
Races in collection are a very
common mistake.
So, in Xcode 9 we are now able
to detect them in both Objective
C and Swift.
Note that this requires that you
are using macOS, High Sierra and
iOS 11.
But we are able to detect races
on NS mutable array and NS
mutable dictionary and also on
Swift array and Swift
dictionary.
And with that, I'd like to show
you how this works in practice.
So, I was able to get the source
code of a very old version of
the WWDC app before it adopted
Swift code.
So, this version that I have is
still completely written in
Objective C, as you can tell
from this copyright header.
It was mostly written in 2011.
So, because it was written
several years ago, it's using
some outdated concepts like an
explicit threat for
synchronization instead of GCD.
But I'd like to show you that
thread sanitizer works just fine
even with other synchronization
mechanisms.
So, this file that I'm showing
to you is implementing a class
called WWDC URLConnection, which
serves as a base class for all
networking done from this
application.
And what I did is that I have
planted a multithreading bug in
this code.
And let's see if the Thread
Sanitizer can find this bug.
So, first let me make sure that
I have Thread Sanitizer enabled
by going to product scheme, edit
scheme.
Which brings out, brings the
scheme editor.
And you'll see that I have
Thread Sanitizer enabled.
So, let's now run this app in
the simulator.
And as soon as the app launches
in the simulator, it will
already initiate several network
connections.
So, it should already exercise
this file that I'm showing you.
And you can notice that Xcode is
already reporting a race in the
issue navigator.
So, this issue is reporting that
we have a race.
So, let me click it so we can
get to the line of code that
contains this race.
So, in this case we see that we
are adding some object into a
mutable array.
The purpose of this code is to
maintain a list of active,
currently active connections.
So, we are tracking that for
debugging purposes.
So, as soon as we're creating
some new URL connection, we will
add it to this list.
But this can happen from any
thread.
Any thread can create a new URL
connection.
And if we take a look at the
details of the issue one more
time in the navigator, we will
see that that is the case.
Because there's thread three
trying to call add object.
And thread five, also trying to
call add object into the same
mutable array.
And if we take a look at the
callers of that API, we will see
that they all both point to the
same line of code.
So, that is a problem.
We are accessing this mutable
array from multiple threads
without any synchronization.
And to fix it, I can actually
fix it very easily.
Because I have noticed that the
code right after this line is
already doing some
synchronization.
It's using this API called
perform block that dispatches
some work onto a specific
thread.
In this case, it's called
connection thread.
So, which is an explicit thread
that is used for
synchronization.
And since it's a single thread,
it will provide synchronization
exactly with the work serially
simply because it's a single
thread and there's no
[inaudible] going on.
So, to fix this I can just move
this call to add object into
that synchronized block like
this and that should fix our
race.
Because now we will also only be
accessing the active connection
array within the synchronized
block which is only executed
serially.
So, now let's run the app in the
simulator one more time to see
if that fixes our race.
And again, once the app
launches, it already triggers
several network connections.
So now when it's up and running
we'll see that Xcode is no
longer reporting any Runtime
issues.
[ Applause ]
So, you've seen how Thread
Sanitizer finds a race in
Objective C code.
What about Swift?
The same detection works in
Swift code as well.
So, in this case if we have an
array of strings and we have two
threads, let's say one thread is
looking up the value from this
array while some other thread is
writing to it.
We'll detect this race and
Thread Sanitizer will find this.
Fixing this again can involve
using a serial dispatch queue
and then making sure that the
only access that array within
some synchronized blocks.
So, in this case thread one,
we'll be using queue.synch which
is necessary in this case
because we need the output value
from this computation to
continue.
We need that lookup in the
dictionary to give us an answer.
So, we need to wait for the
result.
So, I'm using queue.synch here.
But for the second thread, I can
use queue.asynch because that
block is not providing any
output so we don't need to wait
for it to finish.
So, you might have noticed that
in the previous example I did
not call the problem a data
race.
Instead, the warning said it's a
Swift access race.
Swift access races are
violations of a more general
rule which applies to all
structs, not just arrays and
dictionaries but all structs.
Even the ones that you define.
So, this is a new rule that is
now present in Swift 4.
And part of it states that
mutating methods on structs
require that you have exclusive
access to the whole struct.
This does not apply to classes
because classes don't have
mutating methods.
And any methods on a class can
change any property and it only
needs to have exclusive access
to the properties that the
method changes.
So, this new rule that's applied
to structs is now being even
enforced by the compiler, both
statically at compile time and
dynamically at run time.
But this enforcement mostly
applies to single-threaded
violations.
And Thread Sanitizer is here to
help you with the multithreaded
cases.
And if you'd like to learn more
about these new rules in Swift
4, I recommend that you watch
the What's New in Swift session.
And explicitly a session that
was called Exclusive Access to
Memory which describes what the
new rules are.
And it also talks about what is
enforced.
But let's take a look at one
more example.
Let's say that a friend has
asked me to write some software
for his spaceship.
So, we'll have this struct which
describes the location of this
spaceship.
So, it will have some stored
properties to describe the
coordinates in both space and
time of course.
And will have some methods on
this struct as well.
Because the spaceship can
teleport to a different planet.
It can also fly to a different
city on the same planet.
And of course it can travel in
time.
And since these methods are
changing the coordinates, they
need to be mutating methods.
And that also means that the
rules that I just mentioned
apply to these methods.
So, if you have two threads,
which are both trying to change
the location of our spaceship.
Let's say thread one is trying
to teleport it to a different
planet while the second thread
is trying to move it in time.
That is a Swift access race.
And notice that it doesn't
matter which stored properties
are these functions, these
methods accessing or changing.
Even if teleport only changes X,
Y and Z while the other method
only changes time, it's still a
Swift access race.
The rules simply state that you
need to have exclusive access to
the whole object when you are
calling a mutating function,
sorry, to the whole struct.
It's also important to
understand that if we try to fix
this problem by introducing some
synchronization into that
struct.
Let's say that we will try to
use a dispatch queue inside of
that struct and protecting the
bodies of the mutating functions
inside them, that's not enough.
That's not a correct fix and
it's still a violation and still
a Swift access race.
Because we need to have that
exclusive access to the struct
in order to call that mutating
function.
And it's not enough to try to
introduce the synchronization
inside that function.
The correct fix is to move the
synchronization to the caller of
those mutating methods.
So, let's say that we have a
class that describes the whole
spaceship.
And it's a good idea to use a
class here because this
spaceship has some identity.
It doesn't make sense to make
copies of it.
So, in this case the spaceship
can protect the location stored
property with a queue.
And if we make sure that the
methods are only accessing that
struct within synchronized
blocks such as queue.synch here.
That will make the whole class
thread safe.
So, we've learned that you need
to synchronize access to your
shared mutable variable.
And you can use GCD for that
task and it's often as simple as
just associating your data with
some serial queue and then only
accessing the data from that
queue.
Thread Sanitizer is an amazing
tool that helps find you the
places where you are missing the
synchronization.
Which is, you know, a problem
that is very easy to make.
And with that, I'm very excited
to tell you that we're, this
year, introducing another
sanitizer to help you catch even
more types of bugs.
And here's Verdant to tell you
about it.
[ Applause ]
It's all yours.
>> All right.
Hello. My name is Verdant and I
work on compilers.
And I'm really happy to tell you
that this year in Xcode 9 we're
releasing a new tool, Undefined
Behavior Sanitizer.
And I'm sure it's going to help
you catch lots more bugs.
Okay. What is Undefined Behavior
Sanitizer?
Well, just like the other
Runtime tools you've seen so far
in this talk, it's a Runtime bug
finder.
Now, as the name suggests,
Undefined Behavior Sanitizer
detects undefined behavior for
you.
But so does Address Sanitizer
and so does a Thread Sanitizer.
What's special about Undefined
Behavior Sanitizer is that it
specializes in checking unsafe
constructs in the C language
family.
It's compatible with other
Runtime tools.
It works on all of our devices
and platforms.
And if you're interested in
learning more about undefined
behavior, I highly recommend
that you check out tomorrow
morning's talk about
understanding undefined
behavior, 9 am.
That talk will go over what
undefined behavior is.
Why it exists.
And how it can affect your
applications.
Now, I've got some good news for
you.
Undefined Behavior Sanitizer can
detect over 15 different kinds
of new issues.
Now, this is going to be great
for productivity but for this
talk, just to give you a taste
for what Undefined Behavior
Sanitizer can actually catch and
how it works, we're just going
to focus on three issues.
Integer overflow, alignment
violations and the nonnull
return value violation.
Let's start with integer
overflow.
Integer overflow occurs when
you've got an arithmetic
expression and its result is too
big to fit in a variable.
Now, if this sort of bug occurs
in an indexing expression, such
as, like, if you're indexing
into a buffer or in an
expression used to compute the
size of the buffer, it can
actually be a serious security
hole and it can be exploited.
Integer overflow can also just
sometimes lead to surprising
results.
Like, for example there
additions you can perform that,
well, take a look.
If you've got int max and you
add 1 to it, you actually don't
get a number that's bigger than
what you started out with, which
can be really confusing.
Now, not all kinds of integer
overflow are undefined behavior.
In fact, some kinds of overflow
actually have defined semantics,
which is unsigned integer
overflow.
However, unsigned integer
overflow can still be really
surprising.
So, we really recommend that you
opt into this check.
I'll show you how to do that at
the tail end of this topic.
But with that, let's go ahead
and jump into a demo.
All right, now what I've got up
here is a function that all of
us have probably written really
often.
It's an average function.
So, it takes in an array of
integers and a length.
It sets up an accumulator.
It iterates through your array,
adds everything up and divides.
So, it should give you an
average.
Now, we're interested in writing
a test for this so that we know
that it behaves correctly.
So, here we go.
Let's take a look at the test
that we've got.
Test nonnegative average.
The test is really simple.
So, we're going to create an
array of 10,000 integers.
We're going to populate the
array with pseudo random
nonnegative integers and just
check, just do a simple sanity
check.
Just check that the average that
we get back is also nonnegative.
That's this assertion right
here.
All right, so let's go ahead and
run our test.
Let's go up to here.
Hit play. Build succeeded.
And nothing really happened.
We just finished running our
program, the assertion passed.
Everything seems great.
Now, let's just change one small
thing.
And this is going to illustrate
why undefined behavior and
integer overflow in particular
can be really tricky.
Let's change the array length
from 10,000 to 10,0001.
Save it. Go back.
And run our program.
Uh oh. Insertion5 failure.
Now, this is really confusing.
So, you know, I've got
non-negative integers.
I wrote a really sort of
straightforward function that
sums them up.
But all of a sudden I'm getting
this weird failure, this really
basic test that it isn't
passing.
Undefined Behavior Sanitizer can
be really useful in these
situations and clarify what the
actual issue is.
So, we're going to turn it on
just like Kuba has shown you.
We go into the scheme editor
next to it, the diagnostics tab.
Click the right check box.
And we're good to go.
We can hit run again, rebuild
but Undefined Behavior Sanitizer
turned on.
And here we are.
So, Undefined Behavior Sanitizer
has zoomed in on the exact cause
of the issue for us and it's
done so in a relatively
drama-free way.
It tells us what happened.
Assigned integer overflow.
And it tells us the values
involved in the overflow.
As we can see, they're gigantic.
There's no way that these two
values or the sum of them can
fit inside of a 32-bit integer.
And what ended up happening was
that whatever garbled result we
got ended up being, you know, in
two complement representation a
negative number.
So, you can fix this problem in
a couple different ways.
The two I would recommend is to
either use a different algorithm
for computing your average or if
you're in a pinch, just
constrain the set of inputs into
your average function so that
you don't end up with this
problem.
All right.
So, with that said, let's go
back to the slides.
I hope that you've seen that
Undefined Behavior Sanitizer can
make it really easy for you to
find the source of tricky issues
that cause weird failures at
Runtime.
All right.
With that out of the way, let's
talk about the second kind of
issue that we're going to focus
on.
And those are memory alignment
violations.
Now, every type in C has a size
but it also has a required
alignment.
A memory alignment violation
occurs in your program when
there is an unaligned load or
store to a piece of memory.
Now, this can actually be a
really subtle bug to find.
And there's a good chance that
you may never even see it during
your day to day development.
I'm assuming most of you develop
your apps in frameworks and the
debug configuration in Xcode.
And when you're ready to finally
ship your app, you'll, you know,
ship it in the release
configuration.
The problem is because the
compiler really expects you to
not violate alignment
assumptions, the optimizer can
often do things with your code
which cause your program to
crash at Runtime in the release
configuration when these
optimizations are enabled.
Undefined Behavior Sanitizer can
help you catch these issues even
in the debug configuration ahead
of time so you don't end up with
hard to debug failures later
down the road.
Now, this type of failure is
especially common in code that
deals with serializing or
deserializing data from
persistent storage.
So, let's take a closer look at
an example that does exactly
that.
Okay, so in this example, I'm
interested in writing a custom
network protocol for a chat
application that I'm developing.
And one really basic thing that
I've got in my network protocol
is a definition of a packet
structure.
The packet structure contains
three things.
A magic field to identify the
protocol that we're speaking in.
A payload length that tells you
how long the message inside of
the packet is.
And the payload itself.
For the purposes of this
example, I'm just going to
assume that int is a four-byte
integer.
Okay, now with that out of the
way, we've got two things that
we need to focus on in order to
make custom network protocol
work for us.
Sender and a receiver.
We'll get to the sender first.
Now, the sender's got a network
buffer.
This is where it's going to
assemble its packets, get them
all ready.
Get your payload ready.
And then shoot them down the
network so that the receiver can
get it.
Now, for illustrative purposes,
I've broken up the memory inside
of our network buffer into
four-byte chunks and hopefully
you'll see why soon.
Okay, now I really miss Kuba
already just because, you know,
he's been offstage for so long.
So, the first message that I
want to send to Kuba is Hey
Kuba.
So, in order to do that I'm
going to start with a magic
value.
Next I'm going to specify the
length of my message.
It's got nine characters in it.
So, there we go.
Finally I'm going to specify my
message itself which is Hey
Kuba.
Now we're ready to take a look
at what the receiver does.
It's going to take a pointer to
the network byte stream's buffer
and cast it to a pointer to a
packet structure.
Then it's going to look inside
the packet, figure out what the
magic field is, make sure it's
the correct values so that we're
speaking the right protocol.
And then look at the payload.
All right, so that's the first
packet out of the way.
No issues so far.
Let's send another.
The second message is going to
be how's it going?
So, we'll do the same thing.
Toss in a magic value, the same
one as before.
Toss down the length of the
message, 15 characters, and then
the message itself.
Switching back over to the
receiver end, we're going to see
that the problem manifests here.
This time we're looking at index
17 into the network byte stream.
And as soon as we look at the
magic value inside of that
packet structure, we get a
memory alignment violation.
Now, as you can see here, the
magic field of the second packet
isn't aligned to a four-byte
boundary.
So, dereferencing it directly
from the network byte stream is
an alignment violation,
something that undefined
behavior sanitizer can very
precisely diagnose for you.
How do you fix this?
Well, we're going to talk about
two different ways to do it.
The first is to use the packed
attribute in your network packet
structure definition or any
structure that you've got that
you're serializing.
Okay, so let's take a look at
how this works.
You add the packed attribute and
that changes all of the field
alignments inside of your
structure from whatever they
were originally to one byte
aligned.
That's the lowest possible
alignment that you can have
which means that any subsequent
load or store from that field is
always going to be aligned.
Aha, so you may be thinking to
yourself this sounds super
convenient.
I'm just going to toss packed on
everything.
Well, you've got to be careful.
So, using the packed attribute
can actually change the layout
of your structure.
In many cases, it can remove
padding that the compiler has
automatically inserted into your
structure and it can also
degrade your app's performance.
Now, if you find that you're not
in a situation where packed
attribute would work for you,
there is another option.
You can use the mem copy
function to perform an unaligned
copy from the network byte
stream or wherever you're
deserializing from.
Into a aligned variable which
can either be in the stack or
the heap.
This mem copy is safe and the
compiler in many instances can
optimize it so that it's just as
fast as the unaligned access,
the original unaligned access
would've been.
So, that's alignment violation
detection with Undefined
Behavior Sanitizer.
Let's move on and talk about the
third kind of bug.
The nonnull return value
violation.
This kind of issue occurs when
you've got a function whose
return value is annotated with
the nonnull attribute.
Annotation, excuse me.
However, the function breaks the
contract imposed by the nonnull
annotation and returns a nil
value anyway.
Now, this can cause crashes if
you're using Objective C APIs
which, you know, violate the
return value annotation from SWF
code.
And it can also cause other
problems if you're using
Objective C APIs which rely on
nullability connection
correctness more stringently.
That's why we recommend that you
opt into this check if your
application makes use of
nullability annotations.
Let's take a look at an example
of the return value, the nonnull
return value violation.
Okay, so in this example I'm a
budding astronomer and I've got
a model of the solar system.
The first thing that I'm
interested in modelling are the
moons in my solar system.
So, here we go.
We've got planet earth and the
biggest moon on earth is the
moon so let's stick that in.
We've got Mars and we're going
to sort these lists by diameter
in decreasing order.
So, Phobos is the largest moon
of Mars.
Amos is the second largest.
Great, but, uh oh.
It looks like we've got an entry
that snuck in here which
shouldn't be around anymore.
So, this is embarrassing.
Better get rid of it.
All right, that's a lot better.
Okay. So, I got rid of some
legacy code from my example.
Now my list is looking better.
Let's move on.
Okay, so what I'm really
interested in figuring out are,
is, I want a list of the biggest
moons for all of the planets in
the solar system.
So, I'm going to do that by
constructing an NS mutable array
and then adding the biggest
moons for each planet that I've
looked up.
Now, the problem here is that
I've looked up the biggest moons
for Pluto and that's not an
entry in the NS dictionary I set
up.
So, I get back nil.
Undefined Behavior Sanitizer can
diagnose this issue for you.
Okay, so that's a look at what
kinds of issues Undefined
Behavior Sanitizer can find for
you and how the tool works.
I want to wrap up the section of
the talk by showing you how you
can enable the opt-in check set
I mentioned.
This is the project build
settings editor.
Here's where you can go to turn
on unsigned integer overflow
detection and also your
nullability annotation checks.
So, that's Undefined Behavior
Sanitizer, new in Xcode 9.
[ Applause ]
We've taken a look at a lot of
different Runtime tools in
Xcode, some new, some improved.
But it's worth taking a step
back and thinking about software
quality itself.
How do you use these Runtime
tools effectively?
There's two main parts to it.
You've got to exercise more code
with these tools turned on and
you've got to use these tools
together.
Let's take a look.
Runtime tools can only catch
bugs for you when you run the
code that contains the bugs.
Maybe the [inaudible] is not the
best way but you've got to
actually run the line of code
that contains the issue for, in
order to get any sort of useful
diagnostic about the bug.
All right?
So, in order to exercise as much
code as possible and find as
many issues as possible, we
really recommend that you use
Runtime tools for daily
development.
We also recommend that you turn
these tools on at least once
before every software release so
that you can avoid spreading
bugs and possibly security
vulnerabilities to your users.
Using continuous integration can
make using Runtime tools much
easier and it can also really
simplify the process of
exercising as much code as
possible with these tools turned
on.
It can ensure that these bugs,
that bugs in your program are
caught as quickly as possible as
soon as you check in code.
And it can also help you track
code coverage in your
application so you can see
exactly how much code is being
exercised every time your CI
runs.
If you'd like to learn more
about how continuous integration
and code coverage work in Xcode,
I recommend that you check out
the WWDC 2015 talk about that.
The second component to using
Runtime tools effectively is to
use them together.
The more of these tools you turn
on, the more issues you can
find.
There's one exception.
So, Address Sanitizer and Thread
Sanitizer are not mutually
compatible.
You won't be able to turn these
two on together but the rest of
the tools you can.
And as we've seen already, all
of these tools can be turned on
by going into the scheme editor
in Xcode and clicking at the
diagnostics tab.
Now, you may be wondering, This
sounds like a lot of overhead,
right?
I'm here to tell you that that's
not really true, in my
experience at least.
So, we've got some numbers for
you about the execution and
memory overheads of these tools.
And what I've found that, at
least in my own experience, I'm
able to turn multiple Runtime
tools on simultaneously while
debugging the entire Xcode app
and the UI still feels
responsive.
Hopefully this information can
help you make the best decisions
about which tools to turn on in
your local setups versus in
continuous integration.
But I hope that the takeaway
here for you is that all of
these tools re incredibly
valuable.
They all catch different sets of
bugs for you and they're all
really worth turning on in some
form or the other.
So, to wrap it up.
Xcode 9 is going to help you
catch more critical bugs in your
apps and programs than ever
before with new and improved
Runtime Tools.
I really hope that you use them
early and often to save time
while debugging and to keep your
users safe.
And with that, I hope that you
go out and squash some bugs.
If you want to find some more
information about this talk,
we've got a website set up for
you with a lot of helpful links.
There are also some related
sessions coming up.
So, what's new in SWF.
Debugging with Xcode 9.
There's a talk about DCD.
And there's also a talk about
what's new in LDM for those of
you who are interested in the
underlying sanitizer technology
that powers Runtime tools.
So, with that, thank you for
coming.
I hope you have a great
conference.
[ Applause ]