21 dangerous pieces of code and programming missteps

Software powers social networks, controls vast supply chains, gets astronauts to the moon and back, and saves lives. It can also screw up horribly—causing programs to crash, systems to become vulnerable, and entire servers or data centers to go down.

And it doesn’t necessarily take a lot of code to do this—just enough of exactly the wrong thing. Here’s a salute to the truly terrible choices developers have made and, sadly, will make. Sometimes you only learn by making mistakes, but maybe some people can learn from others and spot the pitfalls ahead before they fall in.

System-breaking code

Just a little code can do a lot of damage. This is why you need to know what you’re doing when the safety measures are off.

Delete the company

There may be times that you want to delete an old directory. But when you take out the entire drive, from the root down, in Unix, it’s ugly. Better pray you have a recent backup.

The command:

rm -rf

In context:

sudo rm -rf –no-preserve-root /mnt/hetznerbackup /

The space before the last backslash is what unintentionally caused the self-destruct.

Lose all your customers

“[PHP] comes with a host of functions that are important to turn off unless you specifically need them,” said Job Brown, web team leader of U.K.-based e-commerce vendor Wooden Blinds Direct. That includes the ability to eradicate your entire set of customers. “That semicolon is the difference between dropping your whole customers table rather than just the customer with an ID of 1,” he said.

DROP FROM Customers; where id = 1

One more time

Another example of a potential disaster comes from a Quora answer by Colin Turner, a professor of engineering education at Ulster University. It’s a fork bomb written in C that will repeatedly create other processes until the system completely runs out of resources because there is no condition for termination.

#include int main(void) { while(1) fork(); }

Watch those typos

Over at Stack Exchange, there was a discussion of bad programming mistakes in C. Some of the classics revolve around the theme of having typos in conditional statements that always cause the condition to evaluate to true. Here are a couple of variations. In the first example, variable c is assigned the value 1, while the second example always evaluates to a true condition, so any code always executes:

if (c = 1);

if (a == true);

Overlapping scheduled processes

John Chapin of Capital Technology Services remembers a project that called the Unix cron(). The original developer wrote a task to track user activity by the hour. “But there was also an odd condition that the server would inexplicably run out of memory and need to be rebooted every few weeks,” he said. As it turned out, one round of analysis wouldn’t be done before the next started, and eventually the overlapping processes took up all the system resources. His team found the problem and solved it by breaking the processing up into pieces.

Way too long

Chapin also had another good nomination, but one that can’t be shown because it won’t fit on a screen, which was the problem. It was in a Ruby on Rails controller that gathered all clients within a set number of days and then would do some processing.

“Every time the query ran, it would roll through an entire table of 250,000 records about 20 times,” taking two minutes, he said. The problem was that the method was all on one line and it was so long that no one could parse it. Reformatting and changing the table’s keys eventually dropped the load time to 10 seconds.

If you could read this line of code, then it wouldn’t be a problem.


Leave a Reply

Your email address will not be published. Required fields are marked *