Hacker News Reader

> 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