Please post your nominations for Best of Code Review 2013 — Exterminator category: Answer that points out the most interesting obscure bug in the original code.
In your nomination post, be sure to include a link to the answer, as well as a summary of how the bug is interesting and obscure. One nomination per post, please. Answers being nominated must date from 2013.
Asker's problem was that, after a certain amount of time, the program inexplicably slows down. In this case, the Asker knew there was a problem, but, had no idea what, and gave very little information that would point to the issue.
The bug in this case is the subtle interaction between multiple levels of call hierarchy, and that what was considered a performance enhancement in initial versions of Java (when memory was very expensive) has become (in special cases) a hinderance.
By themselves, the following code processes are fine:
At face value there does not appear to be any problem, but, by knowing the internals of how String, StringTokenizer, and Java memory management work the bug becomes apparent: the code is saving the entire file in memory, instead of just a small portion.
The OP notes that the code does not work in Python 3, and speculates that the problem has something to do with PEP 3113 (an incompatible change in argument passing). But this is a red herring: the actual bug is caused by a combination of two incompatibilities. First, the built-in function filter returns an iterator in Python 3 (rather than a list), and that causes a TypeError to be raised. Second, Python 3 uses the __bool__ special method to convert an object to a Boolean (rather than the __nonzero__ special method) and this causes Python's context manager implementation to incorrectly think that it has been asked to suppress all errors.
Tongue in cheek
This is an obscure bug (since cobol is obscure - only one question ever on CodeReview, the bug is obscure by default). Additionally, the bug is intermittent (OK, it happens often, but not always). It is a mind-set issue in COBOL where date/time values are stored as a 'human readable' decimal representation, and not using an epoch. (and then, as we all know, to save space they often used 2 digits for the year... and, before you chortle and say 'how silly', it is only 25 years now to the Y2k38 )
The code prints the Hardy-Ramanujan number, 1729, as expected. It turns out that the correctness of the output is a fluke (see the "False proof" bullet point in the answer).
