Hacker News Reader

Fuzzing is awesome. I just discovered an accidental O(2^n) code path in my project with fuzzing and fixed it: https://github.com/elves/elvish/commit/9cda3f643efafce2df567...

Edit: shortly after I wrote this comment, fuzzing discovered another pathological input - and that was fixed in https://github.com/elves/elvish/commit/04173ee8ab3c7fc4a9e79...

(In case people are curious, the project is a Unix shell, Elvish: https://elv.sh)

View on HN

> I just discovered an accidental O(2^n) code path in my project with fuzzing and fixed it

I've used fuzzing to find crash/panic conditions in Go, but never to find slow paths. How does that work?

It timed out. Since this case is O(2^n) the fuzzer managed to build a relatively short input that caused the function to not terminate for a few minutes.

Oh wow, I misread your original post as O(n^2) and thought “no way a fuzz test would notice mere quadratic time complexity”, but exponential is another beast entirely :-D

Mere quadratic time complexity is something I would expect to timeout and catch at fuzzing time, as long as we do encourage non-tiny inputs, say 10K and beyond.

Oh, fair. I wonder if there is a practical, general way to test for expected time complexity using fuzz tests…

Reply on news.ycombinator.com