I did a talk [0] at the LISA conference back in 2013 with a narrative around the same stat "bug" and how it caused a huge outage when we were in the final days

I did a talk [0] at the LISA conference back in 2013 with a narrative around the same stat "bug" and how it caused a huge outage when we were in the final days of rendering a movie. Instead of debugging I was focussing on how complex systems fail. (If you just want the stat story watch the beginning, skip to 14:00 and then from 41:30 for the conclusion.) While I love reading about how someone can patch a binary to work around this, to me it's more interesting to think about the systemic failures. The problem ultimately is that one system is sending another a response that it can't handle, but the original Unix API has made this impossible to handle. In fact in both this article and my talk, receiving a 64-bit inode causes the segfault, but neither program was asking the filesystem for an inode in the first place. (Ultimately the fix in TFA was to ignore the result of the stat call.) It's amazing that software works at all when you're dealing with latent 25 year old "bugs" that are really just badly designed APIs and poorly implemented specs. And the organisational failures that force us to maintain compatibility with ancient binaries without access to the source. The author here did a great job working resolving something that a lot of folk would have just walked away from. [0] https://www.usenix.org/conference/lisa13/drifting-fragility https://www.usenix.org/conference/lisa13/drifting-fragility