11 Characters That Crash Any PC: the Fork Bomb!

Weighing in here: One of July's most informative videos on the entire YouTube platform. it's a pity that Dave doesn't have more followers, his work is really good.

We had a guy back in college (in the 80s) accidentally code a fork bomb in C. His was due to lack of error checking. He had a loop that was supposed to wait for a message, fork and have the child process exec another program passing it that message. What he failed to do was 1. check for an error condition on the exec causing the child process to loop back instead of exiting with the other process. It tried to call another program that he hadn't written yet so that failed. and 2) check for an error on the socket receiving the message. Once 2 processes were trying to listen on the socket, one would fail because the socket was in use. But he ignored that and forked anyway. There were a bunch of us in the computer lab trying to pull an all-nighter on a project, but this guy brought down the VAX and nobody had admin rights to fix it so we just all went home.

I always love it when you see people talking about issues like this, you always get the people telling you not to make video's about it. But they don't understand that anyone with a little time can find the information on issues like this and how to deploy it. It's just sad that people think that if you don't talk about it people can't figure it out on there own. The more that we talk about issues like this the more our systems can be programed to keep them from being hit by bad actors on the net.

For extra fun, make the program exit after forking itself and not start a second copy. It won't take down your system, but you'll end up with an "unkillable" task that runs around memory, possibly upsetting the scheduler.

I did something like this back in the early 2000's in programming class in High School. I was bored with the programming assignments, they were very easy, and the teacher told me to write whatever I wanted. I told her to run it on the isolated test machine in the lab. She was impressed but not happy. lol.

Back when Sun Microsystems made big machines, we had some code that the Sun reps swore would scale but our experience suggested otherwise. It took some work to get a sanitized version of the data to test with (the real data was TS SCI) but we eventually got an unclassified test case. It stalled every machine we tried it on when that machine was running Solaris Trusted Zones, but on the older system running Trusted Solaris it completed just fine, even on really old hardware with little ram and small, slow drives. Eventually someone swore it had to work, we just had not thrown enough hardware at it yet and offered a run on an E15000 (which is essentially an entire data center). At about 20 minutes error messages began to appear and the console began to lag. After 30 minutes it was unresponsive and most of the cores were maxed out. The cores were all swapping memory to disk. At about 8 hours the disk arrays began to fill up. At 12 hours it halted. All disks full, all memory allocated. The same program took about 45 seconds on a Sparc 5! Implementation details matter a lot!

Brings back memories. Back in the early ‘70s I wrote a simple CP/M batch file to test disk drive reliability. It copied one entire 8” floppy disk to another, then deleted the original and repeated the process endlessly - or until the computer crashed, which many did. It earned me the nickname Mad Bomber :-)

Watching Dave's videos is like watching your old friend to tell you wonderful stories about his life.

I remember in college our campus HP-UX machine would go down about once a semester and you’d think, “Guess the OS class is writing their shells this week.”

I remember an IBM engineer telling me about this concept in the 90's when I was an admin for their RS6000 platform. I wrote a shell script on one of the test servers that recursively forked copies of itself as background processes. It had the same effect as this, but your version is so much simpler and is more elegant. I love it!

Dave, I want to let you know your videos are not only interesting but the part that I love the most is the fact you take the time to explain how things work. It truly sets apart your videos from others, and why things are the way they are. Thanks!

Is this what Jeff Goldblum used in Independence Day?

On modern Linux, systemd places each session into a separate cgroup, and the kernel is now pretty good with preventing processes from different cgroups starving each other from resources. However, WSL is not a full modern Linux system based on systemd. It is just the kernel and bash, and none of the other user-level system management glue code (e.g. systemd's out-of-memory kill daemon) that make up bare-metal installed Linux distributions. So there is still a lot of infrastructure missing in WSL2 compared to a native install, and therefore you can't really learn how e.g. Ubuntu 22.04 behaves in such situations from playing with it in WSL2.

Back when I was a student around 2000, I remember writing something similar in a Windows NT command line to see if I could cause a BSOD. Instead, the PC just locked up, requiring forcing power off/on as I couldn't bring up task manager, log out, etc. The batch file is short also, e.g. named "c.bat" containing these 3 lines: :rep start c.bat goto rep This basically launches endless new instances of itself. From Windows XP onwards this just bricks the current user session as it's possible to press ALT+CTRL+DEL and log out, which I remember was not possible in Windows NT.

As a kid I didn't have access to any programming language that could compile into a real .exe. So, I experimented if I could just change the extension of a .bat file to .exe and run it. The result - MSDOS 7 would just restart. The first line of the batch file was - @echo off. I then found out that it was enough for a text file to have a @ at the beginning, save it as .exe and it would restart the PC if run from the prompt.

Ah, it has a name. I accidentally froze my pc twice this way during labs that wanted us to make a recursive program that run recursion using fork.

I recall seeing functionally a similar idea on the Original Star Trek episode “Wolf in the Fold”. Filling the computer's processes and all forms of storage with the digits of Pi, instead of infinite clones, an single program with no known limits on its needs. Different method, yielding a shared result, an over demand for system resources.

Alt-Sysreq-K to kill everything on the current TTY. As a kernel-level interrupt it usually works (unless you have a USB keyboard and the USB system has crashed). If you can invoke loginctl, on an (e)logind system, you can kill the session that way.

As someone who's been running servers shared by my multiple clients for over 15 years, I'm glad you've covered this. My first experience was a learning curve to say the least.

WOW !!! I am 68 and have been building My own water cooled PC's for many years now. 1982ish I purchased a Commodore 128. 1988 I took a train to NYC and underneath GCS or somewhere, I bought a Amiga 500 with the side adapter that was a one meg HD and space for more sticks of RAM. I have never heard of fork bombs in all this time, and ya learn something new every day. Clear Skies Mike