Article: Finding memory bugs in D code with AddressSanitizer

[Johan Engelen]

On Tuesday, 26 December 2017 at 22:11:18 UTC, Jon Degenhardt 
wrote:
> On Monday, 25 December 2017 at 17:03:37 UTC, Johan Engelen 
> wrote:
>> I've been writing this article since August, and finally found 
>> some time to finish it:
>>
>> http://johanengelen.github.io/ldc/2017/12/25/LDC-and-AddressSanitizer.html
>>
>
> Nice article. Main question / comment is about the need for 
> blacklisting D standard libraries (druntime/phobos). If someone 
> wants to try ASan out on their own code, can they start by 
> ignoring the D standard libraries? And, for programs that use 
> druntime/phobos, will this be effective? If I understand the 
> post, the answer is "yes", but I think it could be more 
> explicit.

Indeed, yes. I've used ASan successfully on the ddmd lexer. 
"successfully" = I found and fixed an actual bug with it.
Without ASan-enabled standard libs, ASan testing will cover your 
code and (most) std lib _templated_ code.
A blacklist may be needed for templated std lib code that doesn't 
work with ASan (yet), either because of a bug in the std lib (not 
very likely I think) or something else. We need much more testing 
of LDC+ASan.

> Second comment is related - If the reader was to try 
> instrumenting druntime/phobos along with their own code, how 
> much effort should be expected to correctly blacklist 
> druntime/phobos code? Would many programs have smooth sailing 
> if they took the blacklist published in the post? Or is this 
> early stage enough that some real effort should be expected?

Very early stage. I myself have not worked on ASan-enabled 
druntime/phobos for more than 30 minutes. Already found some 
trouble with cpuid functions (inline asm): `fun:_D4core5cpuid*` 
must be added to the blacklist.
I think the first goal should be to make a blacklist such that 
all tests pass, adding blacklist items in a "# not reviewed" 
section. Then afterwards, we can reduce the blacklist bit-by-bit 
by figuring out exactly why ASan triggers: either a bug, expected 
behavior, or an ASan bug.
A counterpart to the blacklist file is an 
`@no_sanitize("address")` magic UDA; to disable ASan and document 
it inside the code. This should be done in such a way that it is 
upstreamable. (e.g. version(LDC) static import ldc.attributes, 
alias no_sanitize = ...)

> Also, if the blacklist file in the post represents a meaningful 
> starting point,

it does

> perhaps it makes sense to check it in and distribute it. This 
> would provide a place for contributors to start making 
> improvements.

Definitely makes sense. I think this should be inside the runtime 
libraries' repos, right? (So one blacklist for druntime, and 
another for Phobos).
(I'm even thinking about adding `-fsanitize-blacklist=<...>` to 
the shipped blacklist in `ldc.conf`.)

I'll figure out how to incorporate your comments into the 
article, thanks.

cheers,
   Johan