Fixing a 20-Year-Old Bug in Enlightenment E16

In Enlightenment E16, a bug was tracked down and fixed where the middle ellipsis text-fitting routine fell into an infinite loop for certain long window titles.

The issue surfaced as the desktop freezing when opening a PDF, and looking at it with gdb showed that the loop stuck in retry wasn't inside imlib2's font cache internals, but rather in the text width calculation loop outside of it. After examining multiple samples, a 2-state oscillation was observed, where the state kept bouncing between two values.

The root cause was the search logic in TextstateTextFitMB() and its ASCII counterpart.

• It cut the middle of the string and inserted ...
• Then re-measured the remaining width
• Using Newton-style estimation to increase or decrease nuke_count
• But since there was no iteration limit, it would never terminate if it diverged or oscillated.

Also, the termination condition was too tight.

• The tolerance range was nc2 >= 0 && nc2 < 3*cw
• Short strings usually converged with 1-unit adjustments
• But long, ambiguous titles kept bouncing between two points and got stuck

The fix added the same defensive logic to both paths (multibyte/ASCII).

• Limited iterations to 32, and after that, accepted the current attempt if it was valid
• Clamped nuke_count to a minimum of 1 within the loop to prevent malformed strings from negative correction
• Clamped cw to a minimum of 1 to prevent division issues when the width was close to 0

The reproduction case was a long window title. As in the example, the problem occurred when a title of roughly 81 wide chars tried to fit into a title slot of about 291px.

The post ends by noting that the older the code, the more likely such manual optimizations and heuristics are hidden within it, and that unintended bugs can survive for a long time as a result. It mentions the recent kernel stable patch case and the XZ backdoor case as warnings that even small mistakes in the supply chain or maintenance process can lead to major failures.