Today's code snippet comes to us from Tobias Tobiasen. The company he works for used to include a third-party closed-source HTTP client in their product. Being a little worried about having to support their product without the source code for the HTTP client, they asked for a source code license. After paying an obscene amount of money for it (red flag #1) they finally got it.

While browsing though the source code, he found all sorts of odd comments like:

// Somebody must have been smoking hashish when they wrote this

and

// I have no idea what this does but it looks important

That last comment is, obviously red flag #2.

<interrupting thought>
I work with a guy who is never satisfied with a, "I dunno it just works."
He always steps through code, or compiles it in his head and figures it out
(I swear he can compile code in his head)  He says, "It's never good enough to know that it works, because if you don't know why or how it works someday it might stop, and then you won't know why, or how to fix it."
</interrupting thought>

Tobias was a bit worried by the disturbing comments, but the code seemed to work and it had features that no other HTTP client had at the time, so out the door it shipped with their product.

Fast forward a little bit to where their customers started to experience problems with their servers.

Just a little tiny problem: 100% CPU and memory utilization.


They finally narrowed it down to these lines.

           while (!_validConnection) {
               StringBuffer _stringBuffer = new StringBuffer();
               try {
                   while (true) {
                       char _char;
                       _stringBuffer.append(
                           _char = (char)_inputStream.read());
                       if (_char == -1) {
                           break;
                       } else if (_char == '\r') {
                           _stringBuffer.append(
                               _char = (char)_inputStream.read());
                           if (_char == -1) {
                               break;
                           } else if (_char == '\n') {
                               _stringBuffer.append(
                                   _char = (char)_inputStream.read());
                               if (_char == -1) {
                                   break;
                               } else if (_char == '\r') {
                                   _stringBuffer.append(
                                       _char = (char)_inputStream.read());
                                   if (_char == -1) {
                                       break;
                                   } else if (_char == '\n') {
                                       _inputStream.read(
                                           new byte[_inputStream.available()]);
                                       break;
                                   }
                               }
                           }
                       }
                   }
               } catch (OutOfMemoryError error) {
                   // received a bad response, try it again!
                   continue;
               }

Tobias was, obviously, more than a little upset, but soon calmed down enough to fire off a friendly request for support to their supplier.

He even included the lines above along with a nice note about how _char == -1 is not likely be true in the near future and relying on OutOfMemoryError is considered bad practice.

The reply from their support was something along the lines of "We are unable to see any problems in the code, please supply a test case."

i.e. "We didn't want to bother the programmers, plus this code looks fine to us (even though we don't know a compiler from an interpreter) so please do our job for us and figure out how to fix this."

Tobias didn't bother to tell us what his response to this was, but I know what mine would be...

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!