On Saturday, 15 December 2018 at 14:22:48 UTC, Johan Engelen
wrote:
On Saturday, 15 December 2018 at 11:29:45 UTC, Basile B. wrote:
Fuzzed [1] is a simple fuzzer for the D programming language.
Are you familiar with libFuzzer and LDC's integration?
https://johanengelen.github.io/ldc/2018/01/14/Fuzzing-with-LDC.html
No, but i'm not that surprised to see that a fuzzer already
exists.
I may have even seen this article but completely forgot it.
You can feed libFuzzer with a dictionary of keywords to speed
up the initial fuzzing phase, where the keywords are the tokens
strings that you use.
Besides finding crashes, it's also good to enable ASan to find
memory-related bugs that by luck didn't crash the program.
The time to write this announce, already 5 "crashers" found.
Great :)
I have about 40 now
The other day I was reminded of OSS Fuzz and that it'd be nice
if we would setup fuzzing for the frontend and phobos there...
-Johan
I started looking at a crasher:
typeof function function in
which crashes in hdrgen. Actually i realize that i don't like the
D parser. In many cases it checks for errors but continues
parsing unconditionally.
In the example, "in" leads to an null contract that the pretty
formatter dereferences at some point, but parsing should have
stopped after "typeof" since there is no left paren. Now take a
look at typeof sub parser
AST.TypeQualified parseTypeof()
{
AST.TypeQualified t;
const loc = token.loc;
nextToken();
check(TOK.leftParentheses); // <-- why continuing if the
check fails?
if (token.value == TOK.return_)
{
nextToken();
t = new AST.TypeReturn(loc);
}
else
{
AST.Expression exp = parseExpression();
t = new AST.TypeTypeof(loc, exp);
}
check(TOK.rightParentheses);
return t;
}
I think this is what Walter calls "AST poisoning" (never
understood how it worked before today). And the whole parser is
like this.
This poisoning kills the interest of using a fuzzer. 99% of the
crashes will be in hdrgen.
