Best of Code Review 2013 — Exterminator category

Question

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.

Answer 1

Reading Large Files in Java getting really slow

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:

• having input with millions of lines
• reading lines 1 at a time
• parsing each line to locate a small substring of them using a StringTokenizer.
• saving that 'small' string for each line.

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.

Answer 2

Python sudoku solver using simple deductions and brute-force guessing

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.

Answer 3

Critique my COBOL code? I am completely unaware of best practices

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 )

Answer 4

How is my program for computing the Hardy-Ramanujan number?

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