Bugs found through grammar-based fuzzing

Compiler
1

I am currently working on my dissertation on testing compilers and because of that use grammar-based fuzzing to test the compiler.
Fuzzing generated several non-sensical inputs that crash the parser (13) and a lot more that crash the typer (188).
The question is now, shall i report these (parser) issues?

Examples for parser errors (as of 18af52a2a8c89577fab595d8f7977b3a0021c0e4):

.=. >; extension [ : ? (

given ( ? =|. ( ( ( ( ) ( ) ) ) ) { }

. ; class [ e : ? (

Examples for typer errors:

; @ ( [ F. =t.D_- ( ( ( ) ( ) ) ) ( ) ( ) ] =>>

? ; @ d # opaque var -##? J\t `

package .>{ opaque val @

I assume Typer errors are a lot more valuable, so i will try to deduplicate them and obviously recheck them against release.

As an aside, if several files likely trigger the same bug should i provide all/ a couple of them to support debugging?

And as last step, to minimze the inputs i hacked together a bash script that automatically minimizes an input by removing white space delimited words, is there any need or place to provide the script?

9 Likes
2

The question is now, shall i report these (parser) issues?

Yes! By all means.

As an aside, if several files likely trigger the same bug should i provide all/ a couple of them to support debugging?

Yes, please. They may be useful as extra test cases, as well as may lead to uncovering adjacent issues.

And as last step, to minimze the inputs i hacked together a bash script that automatically minimizes an input by removing white space delimited words, is there any need or place to provide the script?

We keep utility scripts here:

Just open a PR, we’ll decide what to do with it during review.