AddressSanitizer workflows?

Jorgen Grahn

unread,

Jan 19, 2019, 5:37:56 AM1/19/19

to

I'm curious how people use Google's AddressSanitizer with Clang and
GCC in practice.

I've toyed with it, by adding this to one of my Makefiles:

CXXFLAGS+=-fsanitize=address,leak,undefined

but my code didn't seem to have those flaws, apart from a leak I knew
about already.

I've used valgrind a lot (in its default modes) so I know fairly well
what to expect from that tool. I know what errors it will flag, how
much slower my code will run (sometimes too slow for use) and I know I
don't have to instrument anything.

- Which sanitizers do people enable, as a rule?

- If you use valgrind, which sanitizers are still relevant?

- When I use valgrind, a segmentation fault crash is almost always
preceded by useful valgrind errors. Is the same true for ASan?

- When do you use them? I suppose at least when running unit and
component tests. Does anyone use them in production?

- I'm unused to tools that require instrumentation. Is it a problem
that the standard library and other libraries aren't instrumented?

- Etc.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Öö Tiib

unread,

Jan 21, 2019, 7:35:52 AM1/21/19

to

On Saturday, 19 January 2019 12:37:56 UTC+2, Jorgen Grahn wrote:
> I'm curious how people use Google's AddressSanitizer with Clang and
> GCC in practice.

Yes, I've used it.

> I've toyed with it, by adding this to one of my Makefiles:
>
> CXXFLAGS+=-fsanitize=address,leak,undefined
>
> but my code didn't seem to have those flaws, apart from a leak I knew
> about already.

I don't care about leaks (since with RAII there are virtually none anyway).
Used _CrtSetDebugSomethingBlah of Visual Studio for that when RAII
wasn't mainstream ages ago, since it was most useful back then.

> I've used valgrind a lot (in its default modes) so I know fairly well
> what to expect from that tool. I know what errors it will flag, how
> much slower my code will run (sometimes too slow for use) and I know I
> don't have to instrument anything.

ASan is good with usage of object after delete/free and all sorts of
buffer overflows.

> - Which sanitizers do people enable, as a rule?

All of these but one at time.

> - If you use valgrind, which sanitizers are still relevant?
>
> - When I use valgrind, a segmentation fault crash is almost always
> preceded by useful valgrind errors. Is the same true for ASan?
>
> - When do you use them? I suppose at least when running unit and
> component tests. Does anyone use them in production?

Use ASan with specially made data for stressing limits (when there
is budget for stress tests) debug with it (when there are symptoms
of those issues) and set up continuous integration to run all tests
with ASan enabled as one CI step (costs next to nothing so always).

> - I'm unused to tools that require instrumentation. Is it a problem
> that the standard library and other libraries aren't instrumented?

There are debug versions (run-time checks of most UB) with most
standard libraries. See docs for details:
https://libcxx.llvm.org/docs/DesignDocs/DebugMode.html
https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html
https://docs.microsoft.com/en-us/cpp/standard-library/checked-iterators?view=vs-2017
These will typically detect if code misuses operators of containers
or iterators; ASan will detect if code misuses pointer arithmetics.

Daniel

unread,

Jan 21, 2019, 10:16:53 AM1/21/19

to

On Saturday, January 19, 2019 at 5:37:56 AM UTC-5, Jorgen Grahn wrote:
> I'm curious how people use Google's AddressSanitizer with Clang and
> GCC in practice.
>
> I've toyed with it, by adding this to one of my Makefiles:
>
> CXXFLAGS+=-fsanitize=address,leak,undefined
>
> but my code didn't seem to have those flaws, apart from a leak I knew
> about already.
>

> - Which sanitizers do people enable, as a rule?
>

> - When do you use them? I suppose at least when running unit and
> component tests. Does anyone use them in production?
>

I had a user of an open source library I'm the author of report a
"misaligned address" warning when parsing CBOR (binary format.) It came
down to a use of reinterpret_cast (undefined behavior) rather than memcpy
(correct behavior), even though the generated assembly happened to be the
same, and the code ran. Since then I've always run travis integration builds with -fsanitize=address -fsanitize=undefined.

Daniel

Jorgen Grahn

unread,

Jan 21, 2019, 11:35:01 AM1/21/19

to

On Mon, 2019-01-21, Daniel wrote:
> On Saturday, January 19, 2019 at 5:37:56 AM UTC-5, Jorgen Grahn wrote:
>> I'm curious how people use Google's AddressSanitizer with Clang and
>> GCC in practice.
>>
>> I've toyed with it, by adding this to one of my Makefiles:
>>
>> CXXFLAGS+=-fsanitize=address,leak,undefined
>>
>> but my code didn't seem to have those flaws, apart from a leak I knew
>> about already.
>>
>> - Which sanitizers do people enable, as a rule?
>>
>> - When do you use them? I suppose at least when running unit and
>> component tests. Does anyone use them in production?
>>
> I had a user of an open source library I'm the author of report a
> "misaligned address" warning when parsing CBOR (binary format.) It came
> down to a use of reinterpret_cast (undefined behavior) rather than memcpy
> (correct behavior), even though the generated assembly happened to be the
> same, and the code ran.

I assume that's -fsanitize=undefined warning about something that will
work on x86, but crash and burn on e.g. PPC? That's a nice feature;
I'm not sure valgrind will warn about that at all.

> Since then I've always run travis integration builds
> with -fsanitize=address -fsanitize=undefined.

Jorgen Grahn

unread,

Jan 21, 2019, 4:18:51 PM1/21/19

to

On Mon, 2019-01-21, Öö Tiib wrote:
> On Saturday, 19 January 2019 12:37:56 UTC+2, Jorgen Grahn wrote:
>> I'm curious how people use Google's AddressSanitizer with Clang and
>> GCC in practice.
>
> Yes, I've used it.
>
>> I've toyed with it, by adding this to one of my Makefiles:
>>
>> CXXFLAGS+=-fsanitize=address,leak,undefined
>>
>> but my code didn't seem to have those flaws, apart from a leak I knew
>> about already.
>
> I don't care about leaks (since with RAII there are virtually none anyway).

In this case I was using a C library with confusing manual memory
management[0] and hadn't wrapped it properly. But often you also want
to run dynamic checkers on others' code to find out how ill-behaved it
is; then leak checking is a useful feature IMO.

> Used _CrtSetDebugSomethingBlah of Visual Studio for that when RAII
> wasn't mainstream ages ago, since it was most useful back then.
>
>> I've used valgrind a lot (in its default modes) so I know fairly well
>> what to expect from that tool. I know what errors it will flag, how
>> much slower my code will run (sometimes too slow for use) and I know I
>> don't have to instrument anything.
>
> ASan is good with usage of object after delete/free and all sorts of
> buffer overflows.
>
>> - Which sanitizers do people enable, as a rule?
>
> All of these but one at time.

Address, leak and undefined, then. I see -fsanitize=thread too.

The GCC manual says some of the sanitizers cannot be used together,
but doesn't say which ones.

>> - If you use valgrind, which sanitizers are still relevant?
>>
>> - When I use valgrind, a segmentation fault crash is almost always
>> preceded by useful valgrind errors. Is the same true for ASan?
>>
>> - When do you use them? I suppose at least when running unit and
>> component tests. Does anyone use them in production?
>
> Use ASan with specially made data for stressing limits (when there
> is budget for stress tests) debug with it (when there are symptoms
> of those issues) and set up continuous integration to run all tests
> with ASan enabled as one CI step (costs next to nothing so always).
>
>> - I'm unused to tools that require instrumentation. Is it a problem
>> that the standard library and other libraries aren't instrumented?
>
> There are debug versions (run-time checks of most UB) with most
> standard libraries. See docs for details:
> https://libcxx.llvm.org/docs/DesignDocs/DebugMode.html
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html
> https://docs.microsoft.com/en-us/cpp/standard-library/checked-iterators?view=vs-2017
> These will typically detect if code misuses operators of containers
> or iterators; ASan will detect if code misuses pointer arithmetics.

Thanks; I (and others) tend to forget that option.

/Jorgen

[0] libxml2. I don't like the existing C++ wrapper, and wanted to see
if I could do without it. Also, my program will exit a
millisecond after parsing anyway ...

Öö Tiib

unread,

Jan 22, 2019, 4:18:42 AM1/22/19

to

On Monday, 21 January 2019 23:18:51 UTC+2, Jorgen Grahn wrote:
> On Mon, 2019-01-21, Öö Tiib wrote:
> > On Saturday, 19 January 2019 12:37:56 UTC+2, Jorgen Grahn wrote:
> >> I'm curious how people use Google's AddressSanitizer with Clang and
> >> GCC in practice.
> >
> > Yes, I've used it.
> >
> >> I've toyed with it, by adding this to one of my Makefiles:
> >>
> >> CXXFLAGS+=-fsanitize=address,leak,undefined
> >>
> >> but my code didn't seem to have those flaws, apart from a leak I knew
> >> about already.
> >
> > I don't care about leaks (since with RAII there are virtually none anyway).
>
> In this case I was using a C library with confusing manual memory
> management[0] and hadn't wrapped it properly. But often you also want
> to run dynamic checkers on others' code to find out how ill-behaved it
> is; then leak checking is a useful feature IMO.

Yes, sometimes libraries contain defects, also standard libraries, also
leaks. So always support exact versions of dependencies and update
those only for reason and as separate pull request. Again major headache
avoided close to effortlessly.

Leaks result with symptom that memory usage grows over time. Sometimes
the leaks are "logical". For example more objects are put into some global
container than erased from it over time. Such leaks can't be detected with
any tool. On worst cases it can be quite challenging to figure it out.

> > Used _CrtSetDebugSomethingBlah of Visual Studio for that when RAII
> > wasn't mainstream ages ago, since it was most useful back then.
> >
> >> I've used valgrind a lot (in its default modes) so I know fairly well
> >> what to expect from that tool. I know what errors it will flag, how
> >> much slower my code will run (sometimes too slow for use) and I know I
> >> don't have to instrument anything.
> >
> > ASan is good with usage of object after delete/free and all sorts of
> > buffer overflows.
> >
> >> - Which sanitizers do people enable, as a rule?
> >
> > All of these but one at time.
>
> Address, leak and undefined, then. I see -fsanitize=thread too.
>
> The GCC manual says some of the sanitizers cannot be used together,
> but doesn't say which ones.

If you have continuous integration then there are no much difference if
it runs tests 2 times or 10 times (with different compilers and combinations
of instrumentation). Computing power is dirt cheap so people waste it on
total trash (like bitcoins). So I quite strongly suggest to do that. Little
benefits add up into greater perceived quality at low cost.

> >> - If you use valgrind, which sanitizers are still relevant?
> >>
> >> - When I use valgrind, a segmentation fault crash is almost always
> >> preceded by useful valgrind errors. Is the same true for ASan?
> >>
> >> - When do you use them? I suppose at least when running unit and
> >> component tests. Does anyone use them in production?
> >
> > Use ASan with specially made data for stressing limits (when there
> > is budget for stress tests) debug with it (when there are symptoms
> > of those issues) and set up continuous integration to run all tests
> > with ASan enabled as one CI step (costs next to nothing so always).
> >
> >> - I'm unused to tools that require instrumentation. Is it a problem
> >> that the standard library and other libraries aren't instrumented?
> >
> > There are debug versions (run-time checks of most UB) with most
> > standard libraries. See docs for details:
> > https://libcxx.llvm.org/docs/DesignDocs/DebugMode.html
> > https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html
> > https://docs.microsoft.com/en-us/cpp/standard-library/checked-iterators?view=vs-2017
> > These will typically detect if code misuses operators of containers
> > or iterators; ASan will detect if code misuses pointer arithmetics.
>
> Thanks; I (and others) tend to forget that option.

Yes, the assertions of library are way easier to comprehend than same
issue raised by ASan for example. Library asserts first so these can
be used as combination, too.