Pretty remarkable this has been sitting in production on millions of devices and nobody noticed until someone tried to formally verify it. Nobody at Google notice the stacktraces in TimSort code? Almost every mobile app I've written in production phones home when the app crashes. Is it just that unlikely to occur?

It was literally impossible for it to occur. The numbers it required were so large that there's no device with enough memory for the bug to show up.

Unless I misunderstand their test code, the article says they could reproduce the problem using an array of 67108864 Integer objects. That doesn't sound like an impossible amount of memory.

It's also noted in the relevant thread on the Python mailing list[1], which also says that this is different from Java with regards to whether or not it can be triggered:

"Since it's impossible to trigger the error on any current machine anyway (no machine has enough memory), increasing the size of the stack would be absurd. If you read the paper, they note that this is what the Java folks first did (they changed this part of timsort in a way that _did_ make it possible to provoke the stack overflow on current hardware)."

[1]: https://bugs.python.org/msg236603

It was impossible in the Python version. Not in Java.

I read this long time back. I believe that Java rolled out a fix later to make it impossible to reproduce.

Not only was it fixed in Java, but Python patched the bug in one day.

https://bugs.python.org/issue23515

Can mods add a [2015] tag to the title? While this is an impressive analysis, it’s not a cause for panic now as it has long been patched.