Finding UI crashes by fuzzing input events with american fuzzy lop

What this gives you is a reliable way to reproduce obscure input scenarios that trigger a crash, which is often the only thing that's missing for fixing long-tail crashes. Of course, if there were now hundreds of such crashes you'd need to start triaging to avoid devoting hours of bug fixing to crashes no one has ever seen or will ever see, but if it's just a dozen rare ones and one high-profile frequent one ... I wouldn't think about triaging yet.

Fixing the other 11 would already make sense for the plain reason that it makes it easier to find more of the severe bugs (because your fuzzing output won't be cluttered by them).

But in general I think an office application is one of the apps where I think a high amount of stability and not crashing even in exotic situations is a clear win. Even if it only crashes for one out of 10.000 users - that's still a lot of crashes and potentially lost work.

Code that can trigger crashes like this often has problems with ownership and/or concurrent access. At least I often get stuck on such code when doing modifications, asking myself how on earth they guard against null ptr derefs etc. In many cases that sneaking suspicion is founded and there really are bugs lurking in the code I'm supposed to extend in some way.

So they deal with this by (1) turning all the automated code quality tools they can on it (2) getting top-notch open source devs to fix the problems the tools turn up.

Result: a more stable application for the users - remember that most of LO's users are nontechnical people relying on it for real work - and a more maintainable code base for the devs.

The reason this is important is that huge important smelly codebases with too few devs will increasingly be the norm in the future, and LO is developing important tools of attack.