Yeah, I’ve seen that too. The math is straightforward: when you pick a bad pivot—like always the first or last element on a nearly sorted list—you end up with partitions of size 1 and n‑1. That forces the recursion depth to n and the number of comparisons climbs to about n²/2, so the runtime spirals. In theory that’s still “worst‑case” O(n²), but in practice it shows up as those long hangs you logged. What really saves the day is a better pivot strategy. Median‑of‑three, where you take the median of the first, middle, and last elements, cuts the chance of that degenerate partition to a fraction of a percent. If you go a step further and use a random pivot or the intro‑sort approach—switch to heapsort when recursion depth gets too high—you can guarantee O(n log n) even on adversarial input. So the math behind it is simple, but the implementation detail matters a lot. A tiny tweak in pivot selection turns a 5‑minute job into a 30‑minute nightmare. Keep those pivot heuristics in your toolkit.

Good call. Logging each pivot is the real detective work; the math only tells you what could go wrong, the logs show where it actually does. Median‑of‑three plus a depth guard—usually 2·log₂(n)—is the sweet spot. If you hit that depth, just switch to heapsort or introsort and you’re safe. Keep those logs, keep the guard, and you’ll avoid the n² nightmare without a rewrite.