The other day one of my co-workers tried to prank me by tricking me into running a fork bomb in my UNIX shell. Luckily, I caught on to his shenanigans, and his prank failed. I know lots of people are probably asking the question, "what's a fork bomb?"

Imagine starting with a single process. That process then creates two processes. Each of those processes create another two processes. And each of those...etc.

But what exactly is a fork bomb? explains it pretty well.
In computing, the fork bomb, a form of denial-of-service attack against a computer system, implements the fork operation (or equivalent functionality) whereby a running process can create another running process. Fork bombs count as wabbits: they typically do not spread as worms or viruses. To incapacitate a system they rely on the (generally valid) assumption that the number of programs and processes which may execute simultaneously on a computer, has a limit.

A fork bomb works by creating a large number of processes very quickly in order to saturate the available space in the list of processes kept by the computer's operating system. If the process table becomes saturated, no new programs may start until another process terminates. Even if that happens, it is not likely that a useful program may be started since the instances of the bomb program will each attempt to take any newly-available slot themselves.

Not only do fork bombs use space in the process table: each child process uses further processor-time and memory. As a result of this, the system and existing programs slow down and become much more unresponsive and difficult or even impossible to use.

As well as being specifically malicious, fork bombs can occur by accident in the normal development of software. The development of an application that listens on a network socket and acts as the server in a Client-server system may well use an infinite loop and fork operation in a manner similar to one of the programs presented below. A trivial bug in the source of this kind of application could cause a fork bomb during testing.
So let's take a look at an example of a fork bomb:

: () { :|:& };:

To understand this, let's dissect each bit:

:() # define ':' -- whenever we say ':', do this:
{     # beginning of what to do when we say ':'
:     # load another copy of the ':' function into memory...
|     # ...and pipe its output to...
:     # ...another copy of ':' function, which has to be loaded into memory
      # (therefore, ':|:' simply gets two copies of ':' loaded whenever ':' is called)
&     # disown the functions
}     # end of what to do when we say ':'
;     # Having defined ':', we should now...
:     # ':', initiating a chain-reaction: each ':' will start two more.

Or more simply: forkbomb() { forkbomb|forkbomb & } ; forkbomb

Just note that these fork bombs work by executing them in a UNIX shell. I suppose I could show you one that would work in Windows...out of pure interest, of course ;)

start %0
goto :s