How we found a bug in the hyper HTTP library
22 points by sanxiyn
22 points by sanxiyn
Kind of an un-comfortabe question but how many more bugs like this exist in popular rust libraries. Hyper is a pretty important library and underpins a large part of the rust ecosystem. Parking lot is very similar and also had a bad bug that was semi-recently found. These library maintainers are amazing and do some really good work so I don't mean to denigrate their efforts.
Some of the folks I really look up to are involved in these libraries and use them daily. Folks at Google, Antithesis, Oxide all write some very robust and impressive code. They're all amazing engineers.
I think some of the fear comes from the fact that I'm not sure that this would be something that I would ever be able to debug on my own. I suppose this is one reason why language popularity is important. More users consuming things and more likely to hit edge cases.
Maybe someone can ease my suffering a bit and point me to bugs in other large ecosystems core libraries, I'm sure these hard bugs absolutely exist there too! I think it just really pains me in rust because of the influence of correctness that community drives forward. I suppose such as life and software.
I built Ruby’s most popular connection pool library. It took 5-7 years before we’d found and fixed every last thread safety edge case; we haven’t seen a significant bug in 5+ years now. Robustness takes time.
Awesome! Wow that’s an incredibly long time. How were most issues discovered? From user tickets?
Yep, just lots and lots of production usage. “Battle hardened” means lots of battles, no way around it.
I can't speak more generally, but these kinds of timing-level HTTP bugs are annoying to unravel. I'm working on some tooling for this now, though :)
It's totally unsurprising to me that these would show up, regardless of language.
Even Knuth once remarked that he only proved a function was correct, but he had yet to test it.