Re: Article: Finding memory bugs in D code with AddressSanitizer
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
Re: Article: Finding memory bugs in D code with AddressSanitizer
I posted this on another thread. It succinctly points out what is the
fundamental difference between C++ and D on memory safety:
C++:
int foo(int* p) { return p[1]; }
int bar(int i) { return foo(); }
clang++ -c test.cpp -Wall
D:
@safe:
int foo(int* p) { return p[1]; }
int bar(int i) {return foo(); }
dmd -c test.d
test.d(3): Error: safe function 'test.foo' cannot index pointer 'p'
test.d(4): Error: cannot take address of parameter i in @safe function bar
I.e. in C++, writing memory safe code means using the right library functions.
It is not checkable by the compiler. In D, it is checkable by the compiler.
Re: Article: Finding memory bugs in D code with AddressSanitizer
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 "LDC comes with improved support for Address Sanitizer since the 1.4.0 release. Address Sanitizer (ASan) is a runtime memory write/read checker that helps discover and locate memory access bugs. ASan is part of the official LDC release binaries; to use it you must build with -fsanitize=address. In this article, I’ll explain how to use ASan, what kind of bugs it can find, and what bugs it will be able to find in the (hopefully near) future." 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. 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? Also, if the blacklist file in the post represents a meaningful starting point, perhaps it makes sense to check it in and distribute it. This would provide a place for contributors to start making improvements.
Re: Article: Finding memory bugs in D code with AddressSanitizer
On Tuesday, 26 December 2017 at 08:03:44 UTC, Temtaime wrote: The main font is very ugly. Code font looks ok tw. on the contrary, post font is very readable (might use some letter spacing), clear and beautiful. that is on a retina macbook pro. code blocks are very readable too.
Re: Article: Finding memory bugs in D code with AddressSanitizer
The main font is very ugly. Code font looks ok tw.
