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?
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)."
