Java

import java.util.concurrent.atomic.AtomicInteger; public class Hydra { // Not actually necessary for the leak - keeps track of how many Hydras there are, so we know when they're all gone public static AtomicInteger count = new AtomicInteger(0); public Hydra() { count.incrementAndGet(); } protected void finalize() { new Hydra(); new Hydra(); count.decrementAndGet(); } public static void main(String[] args) throws InterruptedException { new Hydra(); while (Hydra.count.get() > 0) { // Prevent leaks ;-) System.gc(); System.runFinalization(); } } } 

Explanation

You might assume that since there are no references in the code (other than count, which you can safely ignore), it can't leak. However, the finalizer creates two new Hydras, and whilst it doesn't hold references for these either, they'll hang around until finalized. This means that the program only leaks memory during garbage collection - hence the calls to System.gc() and System.runFinalization().

C

Using the C programming language and tested with Linux kernel 2.6.32-49-generic and libc-2.11.1.so.

The only way that the memory can be released is by killing the program in task manager or using taskkill /im yourprogram /f or even restarting the PC.

This is achieved by blocking any signals except for SIGKILL and SIGSTOP.

Closing it should still make it hog memory.

This actually confused me... Killing or closing it both results in termination of the process, allowing the operating system to claim back any memory that was allocated by the process. But then i got to think that by closing it you might mean to close the terminal or any other parent process that executes the memory leaking process. If i got that right, then i solved this problem by blocking any signals, which turns the process into a daemon when the parent process is terminated. That way you can close the terminal the process is running in and it will continue running and proceed to leak memory.

Fork bombs of any sort are banned. That means that infamous bash :(){ :|:&};: is banned!

The process does not fork.

The application must be single threaded only. This implies the fork bomb rule

No new threads are spawned.

The program must not run other program. This means that you cant just do something like run(memoryfiller.exe)

No new processes are spawned.

You can take up as much memory as you like. The more the better.

As much as the operating system can provide.

Code must be explained fully.

Added comments to the source.

And finally here's the code:

#define _GNU_SOURCE #include <stdio.h> #include <signal.h> #include <sys/resource.h> #include <unistd.h> #include <stdlib.h> int main(int argc, char* argv[]) { /* set the real, effective and set user id to root, so that the process can adjust possible limits. if the process doesn't have the CAP_SETUID capability, terminate the process. */ if (setresuid(0, 0, 0) == -1) { printf("Are you root?!\n"); return 1; } /* block all signals except for kill and stop. this allows to terminate the parent process (most likely a terminal) that this process is running in and turn it into a daemon. additionally this makes it impossible to terminate the process in a normal way and therefore satisfies the requirement that closing it should still make it hog memory. */ sigset_t mask; sigfillset(&mask); sigprocmask(SIG_SETMASK, &mask, NULL); /* allow the process to acquire a virtually unlimited amount of memory and queue a virtually unlimited amount of signals. this is to prevent an out of memory error due to a virtual limit for the root user, which would prevent the process from leaking any more memory and to prevent the process from getting killed due to too many queued signals that the process is blocking. */ struct rlimit memory = { RLIM_INFINITY, RLIM_INFINITY }, signal = { RLIM_INFINITY, RLIM_INFINITY}; setrlimit(RLIMIT_AS, &memory); setrlimit(RLIMIT_SIGPENDING, &signal); /* allocate a buffer big enough to store a file name into it that is generated from the process' pid. if the file can be opened (which should always be the case unless /proc is not mounted) the file will be opened and the string -17 followed by a new line written to it. this will cause the oom killer to ignore our process and only kill other, innocent processes when running out of memory. */ char file_name[20]; sprintf(file_name, "/proc/%u/oom_adj", getpid()); FILE* oom_killer_file = fopen(file_name, "w"); if (oom_killer_file) { fprintf(oom_killer_file, "-17\n"); fclose(oom_killer_file); } /* get the size of virtual memory pages in bytes, so the process knows the size of chunks that have to be made dirty to force the kernel to map the virtual memory page into RAM. */ long page_size = sysconf(_SC_PAGESIZE); // allocate a virtually infinite amount of memory by chunks of a page size. while(1) { // will overwrite any previous stored address in tmp, leaking that memory. char* tmp = (char*) malloc(page_size); if (tmp) // make the memory page dirty to force the kernel to map it into RAM. tmp[0] = 0; } return 0; } 

For anyone who's interested in what happens if you keep this program running: On my test system with 2GB RAM and 4GB swap space it took about 10 minutes to fill up the RAM and swap. The OOM killer started its work and three minutes later kind of all processes have been killed. Even mouse, keyboard and display have been dropped by the system. /var/log/kern.log shows no useful information, except for the processes that have been killed.

Pure Bash

Not a fork-bomb, I promise:

:(){ : $@$@;};: : 

It looks a lot like a fork bomb, and uses a similar recursive technique, but no forks. Of course this will run your shell right out of memory, so you are advised to start a new shell before pasting this command.

• Define a function called :
• The function simply recursively calls itself with $@ (arg list) doubled
• After the function definition, the : function is called with an initial arg :

Output:

$ bash $ :(){ : $1$1;};: : bash: xmalloc: ../bash/stringlib.c:135: cannot allocate 536870913 bytes (5368795136 bytes allocated) $ 

^{_{In a previous edit of this answer I did a=$(yes), but I noticed the rule "The program must not run other program", so I need to use pure bash instead without calling any coreutils or anything else.}}

Here's another one:

PLEASE DON'T RUN THIS ON A PRODUCTION MACHINE

:(){ : <(:);};: 

Again, this is not a fork bomb - everything is run from within one thread. This one seems to quite handily bring my Ubuntu VM to its knees, with little room for recovery, other than reboot.

As in the classic fork bomb, a recursive function :() is defined. However it does not fork out calls to itself. Instead it calls itself with one argument, which is itself called in a process substitution. Because process substitution works by opening an file descriptor /dev/fd/n, this not only eats up process (bash) memory, it will also eat up some kernel memory too. On my Ubuntu machine this has the effect of making the window manager inoperable after a few seconds, then shortly after ending up with this screen:

Clicking OK then gives this screen:

None of these options seem to be much help - at this point restarting seems to be the only good option.

XML

<!DOCTYPE boom [ <!ENTITY Z 'ka-boom!'><!ENTITY Y '&Z;&Z;'><!ENTITY X '&Y;&Y;'><!ENTITY W '&X;&X;'> <!ENTITY V '&W;&W;'><!ENTITY U '&V;&V;'><!ENTITY T '&U;&U;'><!ENTITY S '&T;&T;'> <!ENTITY R '&S;&S;'><!ENTITY Q '&R;&R;'><!ENTITY P '&Q;&Q;'><!ENTITY O '&P;&P;'> <!ENTITY N '&O;&O;'><!ENTITY M '&N;&N;'><!ENTITY L '&M;&M;'><!ENTITY K '&L;&L;'> <!ENTITY J '&K;&K;'><!ENTITY I '&J;&J;'><!ENTITY H '&I;&I;'><!ENTITY G '&H;&H;'> <!ENTITY F '&G;&G;'><!ENTITY E '&F;&F;'><!ENTITY D '&E;&E;'><!ENTITY C '&D;&D;'> <!ENTITY B '&C;&C;'><!ENTITY A '&B;&B;'><!ENTITY z '&A;&A;'><!ENTITY y '&z;&z;'> <!ENTITY x '&y;&y;'><!ENTITY w '&x;&x;'><!ENTITY v '&w;&w;'><!ENTITY u '&v;&v;'> <!ENTITY t '&u;&u;'><!ENTITY s '&t;&t;'><!ENTITY r '&s;&s;'><!ENTITY q '&r;&r;'> <!ENTITY p '&q;&q;'><!ENTITY o '&p;&p;'><!ENTITY n '&o;&o;'><!ENTITY m '&n;&n;'> <!ENTITY l '&m;&m;'><!ENTITY k '&l;&l;'><!ENTITY j '&k;&k;'><!ENTITY i '&j;&j;'> <!ENTITY h '&i;&i;'><!ENTITY g '&h;&h;'><!ENTITY f '&g;&g;'><!ENTITY e '&f;&f;'> <!ENTITY d '&e;&e;'><!ENTITY c '&d;&d;'><!ENTITY b '&c;&c;'><!ENTITY a '&b;&b;'> ]> <boom a="&a;"/> 

Then pass the document to an XML parser that doesn't do entity reference loop/recursion detection. For example, xpath included with perl:

xpath boom.xml / 

How it works:

1. The parser encounters <boom a="&a;">
2. The parser expands "&a;" into "&b;&b;"
3. The parser expands one of the "&b;" into "&c;&c;" (on return, it will expand the other "&b;")
4. The parser expands one of the "&c;" etc...

If full expansion could occur, there would be 2^52 expansion of "ka-boom!". Assuming 2-bytes per character, it will try to use 64 PiB. The expansion goes "ka-boom!" at a time, so you can usually watch it use up all memory in top.

This goes by various names, good overview here: http://projects.webappsec.org/w/page/13247002/XML%20Entity%20Expansion

C++

int main() { for(;;)int *a=new int; } 

This code was unexpected! It hung my computer while the task manager was open and showed that it took 890 Mb of memory in 1 second then it also hung. I don't know how this works, maybe it keeps on giving memory to a variable.To explore more of this code I added a statement delete a; and every thing was fine while testing (no hanging) So, I think that the chunk of memory is given (due to new int) and then taken back (due to delete a) to the free space in the new code below.

int main() { for(;;) { int *a=new int; delete a; } } 

So, I conclude that NO RAM IN THIS WORLD CAN HANDLE THIS CODE!!!

EDIT : But many processors can for e.g. intel core 2 duo can't handle this code but
intel core i-series can (worked for me...)

Remember the answer to the question is the 1st code , second one is for explanation.

BrainFuck

+[>+] 

Explanation:

To enter the loop it increases the cell to 1. It moves to the next cell increasing that to 1 as long as the last cell was positive.

Usually A BrainFuck interpreter is flawed with having a hard limit to the number of cells on the tape, but some interpreters adds cells dynamically. These will continue to consume memory until it's no more to consume.

beef is one such interpreter and it's available in the Ubuntu Software Center and my current run on an unused machine started 29 hours ago and has consumed 1GB of RAM in that time. Here's the the output of top

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2978 sylwester 20 0 1030m 984m 2536 R 100,1 12,4 1750:52 beef 

It has 4GB of cache and 6GB of swap so I guess I'll update this answer with how it went in about 12 days.

UPDATE 03.24 17:11

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2978 sylwester 20 0 1868m 1,8g 2456 R 99,9 22,9 6008:18 beef 

UPDATE 03.31 00:20

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2978 sylwester 20 0 2924m 2,8g 2052 R 100,0 36,1 15019:46 beef 

So it's been running for 10 days. Seems like it will be running for at least 10 more before something interesting happens.

C and POSIX

Here I am aiming for a highly portable solution. The problem is that pure C doesn't seem to have a way of telling the Operating System that the memory should remain allocated after the program closes. So I allow myself to use POSIX; most OS's have some claim to POSIX compatibility including Windows, Linux and MacOS X. However, I have only tested it on Ubuntu 12.04 32bit. It does not require superuser permissions.

This solution is essentially the traditional while(1){malloc(1);} solution. However instead of malloc, it uses the POSIX shared memory functions. Since it assigns a shared memory identifier to each allocation, it is still possible to access the memory once the process terminates. Thus the kernel cannot free the memory.

#include <sys/types.h> #include <sys/shm.h> #include <string.h> #define SHMSZ (2*1024*1024) /*Ubuntu rejects shared allocations larger than about 2MiB*/ main() { int shmid; key_t key = 0xF111; /* Lets use `Fill' as our first ID.*/ char *shm; while(1) { /* Like malloc, but using shared memory */ if ((shmid = shmget(key, SHMSZ, IPC_CREAT|0666)) < 0){return 1;}/*Get shared memory*/ if ((shm = shmat(shmid, NULL, 0)) == (void *) -1) { return 1; } /*Attach it */ memset(shm,0,SHMSZ); /*Fill it up */ key++ /*On to the next ID*/ } } 

C#

Forgetting to unsubscribe from events before the handler goes out of scope will cause .NET to leak memory until it throws OutOfMemoryException.

using System; class A { public event Action Event; } class B { public void Handler() { } } class Program { static void Main() { A a = new A(); while( true ) a.Event += new B().Handler; } } 

Explanation: Inside the while loop, we construct a new object, causing the framework to allocate more memory, but we also prevent the new instance of B from being released when it goes out of scope by assigning an instance method to an event in a different class, the result being that the new instance of B becomes unreachable from our code, but a reference still exists, meaning the GC won't release it until a also goes out of scope.

Static events have the same pitfall, since they never go out of scope, they're only cleaned up when the process terminates, unless you unsubscribe from the event first. Always store your references, people!

using System; class Program { static event Action Event; static void Main() { while( true ) Event += new Action( delegate{ } ); } } 

The above works on the same idea, the handler becomes unreachable once the while loop goes out of scope, making it impossible to unsubscribe from the event, meaning the memory will sit there until the program terminates. Static events are arguably more dangerous than instance events, because you can ensure they never go out of scope.

EDIT: You can also do the same with basically any other object as well, just as long as you add a reference while at the same time ensuring there's no way to free that reference.

Here's an example that uses static objects and arrays.

using System; using System.Collections.Generic; static class Leak { private static List<decimal[]> Junk; static Leak() { Junk = new List<decimal[]>(); } public static void Add( uint size ) { decimal[] arr = new decimal[size]; Junk.Add( arr ); } } class Program { static void Main() { while( true ) Leak.Add( 1 ); } } 

Arrays keep being added to the list, but there's no way to clear the list without modifying the code, which would be impossible for closed-source applications. Increasing the number passed to Leak.Add will cause it to leak faster, if you set it high enough it will just result in an immediate OverflowException being thrown.

bash (no external utilities)

No fork bomb here.

Warning: It might kill your shell.

_{Just trying to create an array of integers for reference because I keep forgetting how integers look like.}

while :; do _+=( $((++__)) ); done 

Results in:

xmalloc: expr.c:264: cannot allocate 88 bytes (268384240 bytes allocated) 

J (7)

WARNING: This froze my system when I tried it (Windows 8, J 8.01, in the qt terminal).

2#^:_[_ 

• 2# doubles the length of the argument by duplicating each element,
• ^:_ finds the fixpoint of the given function (but there isn't one so it loops endlessly),
• [_ calls it with _ as the argument.

Haskell (Graham's number)

It's very simple: this calculates the Graham's number

Unlike other examples here, it won't run forever... it will use a lot of cpu, but theoretically it could terminate. if it weren't for the fact that to store the number...

the observable universe is far too small to contain an ordinary digital representation of Graham's number, assuming that each digit occupies one Planck volume.

(according to wikipedia)

import Data.Sequence import Data.Foldable (↑) a 1 b = a ^ b (↑) a _ 0 = 1 (↑) a i b = a ↑ (i-1) $ a ↑ i $ b-1 graham = last $ toList $ iterateN 64 (\i -> 3 ↑ i $ 3) 4 main = print graham 

So, the idea is that the memory will be used by a (series of increasingly) enormous Integer(s) (Haskell's Integers are of arbitrary size).

If you want to test it out, you might have to increase the stack size or load it inside ghci.

Inspired by @comintern.

Replacing /dev/null. Engaging sneaky mode. Requires kernel headers, superuser mode and a working compiler.

# make # rm /dev/null # insmod devnull.ko # chmod go+rw /dev/null 

Have fun.

Makefile:

MODULE := devnull KVERS ?= $(shell uname -r) KDIR ?= /lib/modules/$(KVERS)/build KMAKE := make -C $(KDIR) M=$(PWD) obj-m += $(MODULE).o all: $(KMAKE) modules install: $(KMAKE) modules_install clean: $(KMAKE) clean 

Source code:

#include <linux/module.h> #include <linux/kernel.h> #include <linux/fs.h> #include <linux/ioport.h> #include <linux/device.h> #include <linux/version.h> #include <linux/slab.h> #include <asm/io.h> #include <asm/uaccess.h> #define DEVICE_NAME "null" #define MAJOR_NUMBER 0 MODULE_LICENSE("GPL"); MODULE_AUTHOR("nola <[email protected]>"); MODULE_DESCRIPTION("/dev/null - memory leak style"); MODULE_VERSION("0.1"); MODULE_SUPPORTED_DEVICE("null"); static struct class *class_null; static int major = 0; static int device_open(struct inode *, struct file *); static int device_release(struct inode *, struct file *); static ssize_t device_read(struct file *, char *, size_t, loff_t *); static ssize_t device_write(struct file *, const char *, size_t, loff_t *); static loff_t device_llseek(struct file *, loff_t, int); static struct file_operations fops = { .owner = THIS_MODULE, .llseek = &device_llseek, .read = &device_read, .write = &device_write, .open = &device_open, .release = &device_release }; static int __init mod_init(void) { struct device *dev_null; if ((major = register_chrdev(MAJOR_NUMBER, DEVICE_NAME, &fops)) < 0) { return major; } /* create /dev/null * We use udev to make the file. */ class_null = class_create(THIS_MODULE, DEVICE_NAME); if (IS_ERR(class_null)) { unregister_chrdev(major, DEVICE_NAME); return -EIO; } #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 27) dev_null = device_create(class_null, NULL, MKDEV(major, 0), NULL, "%s", DEVICE_NAME ); #else dev_null = device_create(class_null, NULL, MKDEV(major, 0), "%s", DEVICE_NAME ); #endif if (IS_ERR(dev_null)) { class_destroy(class_null); unregister_chrdev(major, DEVICE_NAME); return -EIO; } return 0; } static void __exit mod_exit(void) { device_destroy(class_null, MKDEV(major, 0)); class_unregister(class_null); class_destroy(class_null); unregister_chrdev(major, DEVICE_NAME); } static int device_open(struct inode *inode, struct file *file) { file->f_pos = 0x00; try_module_get(THIS_MODULE); return 0; } static int device_release(struct inode *inode, struct file *file) { /* decrement usage count: Not. Uncomment the line for less fun. */ /* module_put(THIS_MODULE); */ return 0; } static loff_t device_llseek(struct file *filep, loff_t offs, int mode) { loff_t newpos; switch (mode) { case 2: case 0: newpos = offs; break; case 1: newpos = filep->f_pos + offs; break; default: return -EINVAL; } if (newpos < 0) { return -EINVAL; } filep->f_pos = newpos; return newpos; } static ssize_t device_read(struct file *filep, char *dst, size_t len, loff_t *off) { char *buf = NULL; if (dst == NULL || len == 0) { return -EINVAL; } buf = kmalloc(sizeof(char) * len, GFP_KERNEL); if (buf == NULL) { return -EINVAL; } /* Do how a /dev/null does. */ memset(dst, 0, len); *off += len; return len; } static ssize_t device_write(struct file *filep, const char *src, size_t len, loff_t *off) { char *buf = NULL; buf = kmalloc(sizeof(char) * len, GFP_KERNEL); if (buf == NULL) { return -EINVAL; } *off += len; return len; } module_init(mod_init); module_exit(mod_exit); 

Warning this may force you to reboot!

To remove it:

# rmmod -f devnull # or a reboot # rm -rf /dev/null # mknod /dev/null c 1 3 # chmod go+rw /dev/null 

Ruby

Everyone knows that sum(1/n^2) = pi^2/6

So I can define an approximation function:

pi_approx = lambda {|i| Math.sqrt( 6*( (1...Float::INFINITY).map{|n| n.to_f**(-2)}.take(i).reduce(:+) ) ) } p pi_approx.(100_000) 

Of course the (1..infinity) will run wild.

Notice however that using lazy would make this work ;)

pi_approx = lambda {|i| Math.sqrt( 6*( (1...Float::INFINITY).lazy.map{|n| n.to_f**(-2)}.take(i).reduce(:+) ) ) } p pi_approx.(100_000) #=> 3.141583104326456 

C - 28 25 characters (full program)

Don't run that one, or your system will quickly get frozen!

main(){while(malloc(9));} 

The call to malloc will reserve 9 bytes of memory and request new memory pages from the operating system regularly. The memory allocated by malloc is immediately leaked as no pointer to the returned address is stored. Once the system has run out of memory (RAM and swap space) or the memory limit for the process is reached, the program will break out of the while-loop and terminate.

VBScript

do Set d1 = createobject("Scripting.Dictionary") d1.add true, d1 Set d1 = Nothing loop 

We are creating a dicionary that point to itself. Then we think that we destroy the dictionary by setting it to Nothing. However, the dictionary still exists in memory because it has a valid (circular) reference.

The loop, but also the memory hog, causes the program to hang. After shutdown of the program, the memory is still in use. The system can only be restored by restarting it.

Yes & tmpfs

Why write a new program when one comes for free with Ubuntu?

yes > /run/user/$UID/large_file_on_my_ramdisk 

As you probably know, or have already guessed, Ubuntu mounts /run/user/ by default as a tmpfs which is a type of RAM disk.

You don't even have to close it. It will politely close itself, leaving a nice chunk of memory allocated. I presume yes is a single-threaded, single-process program that does not call any other (writing to an existing RAM disk is also trivially portable to the language of your choice).

It has a minor bug: Ubuntu limits the user writable tmpfs /run/1000 to 100 MB by default, so the swap death feature may not be supported on your machine out-of-the-box. However I managed to fix this on my machine with the following quick workaround:

sudo mount -o remount,size=10G tmpfs /run/user/ 

Bash

Warning: The following code will make your computer unbootable.

printf "\\xe8\\xfd\\xff" | dd of=/dev/sda reboot 

Warning: The preceding code will make your computer unbootable.

Replace /dev/sda with your boot drive. This writes E8 FD FF to the beggining of your boot sector. When booting, the BIOS reads your boot sector into memory and executes it. Those opcodes are equivalent to this assembly:

label: call label 

This is infinite recursion, which will eventually cause a stack overflow.

Haskell

main=print $ sum [0..] 

This tries to add up the counting numbers. Haskell does evaluate the partial sums, it just becomes an infinite addition statement. If you run the compiler with optimization flags, it may not work though.

Bash

Since we can use utilities that aren't specifically designed to consume memory, I focus on a utility to free memory: swapon. This is used to allow the kernel to free up memory by writing to disk.

This script performs two optimizations: (1) Mounting tmp as tmpfs (a type of RAM disk) to make /tmp faster and (2) creating a swapfile to free up memory. Each of these are reasonable by themselves but if a careless user does both then it sets up an cycle of swapping: when the OS tries to swap out pages, it writes to the tmpfs; this makes the tmpfs use more memory; this increases the memory pressure causing more pages to be swapped out. This can take a few minutes on my VM, plenty of time for you to watch the system dig itself into a hole using top.

Closing the program makes little difference since the program itself allocates hardly any memory. Indeed it is not trivial to free memory since you can't free memory by unmounting the tmpfs before you swapoff the swapfile, and that is hard to do until you have freed memory.

This answer could be considered an cautionary tale against blinding applying cool tricks from the net without understanding them.

sudo mount -t tmpfs -o size=9999G tmpfs /tmp # Use tmpfs to make /tmp faster truncate -s 4096G /tmp/swap # Now make a giant swap file to free up memory sudo losetup /dev/loop4 /tmp/swap # Use a loopback so we can mount the sparse file sudo mkswap /dev/loop4 sudo swapon /dev/loop4 #The following line would cause a quick swap death, but isn't needed. #dd if=/dev/zero of=/tmp/zero bs=1 # Zero the tmp dir so the VM can free more memory 

Perl

sub _ { my($f,$b); $f=\$b;$b=\$f; } while(1) { _;} 

Uses circular references. The reference count for the variables will never reach 0, and the references will never be garbage collected.

You might need to be patient, but it is guaranteed to choke your system. The disk would start spinning faster and fumes might be visible.

PHP (linux only):

This code is untested, since that I don't have a linux computer with php running.

But this is my proof of concept:

ignore_user_abort(true); ini_set('memory_limit',-1); ini_set('max_execution_time',0); /* sets php to ignore if the script was canceled in the browser (like clicking cancel or closing the browser) and takes away the memory limit, as well as the maximum execution time. */ function dont_let_it_stop(){shell_exec('php '.__FILE__.' &');} //this function calls the file itself. register_shutdown_function('dont_let_it_stop'); //this function will register the function declared above to be used when the script is being terminated function get_info($f='current') { return str_replace(' kB','',end(explode(':',trim($f(explode(PHP_EOL,file_get_contents('/proc/meminfo')))))))*1024 } /* this function fetches the infos 'current' fetches the max memory 'next' fetches the actual used memory */ $max=get_info();//maximum memory $current=get_info('next');//current memory $imgs=array(imagecreatetruecolor(1e4,1e4)); $color=imagecolorallocatealpha($imgs[$i=0],128,128,128,126); imagefill($imgs[$i],0,0,$color); /* this creates an array and inserts one image (10000x10000 pixels), filling it then with a solid transparent color */ $total-=get_info('next');//calculates the space an image takes while($max-get_info('next')>$total*2)//while the free memory is higher than the memory of 2 images, fill the array { $imgs[$i++]=imagecreatetruecolor(1e4,1e4); $color=imagecolorallocatealpha($imgs[$i-1],128,128,128,126); imagefill($imgs[$i-1],0,0,$color); } //this is just to keep the images in memory, so the script doesn't end while(1)sleep(60); 

This will fill the memory with huge RGBA images (10000x10000 pixels).

The only way to shut this baby down is shutting down the power.

The code is all commented.

Any improvement, doubt, bug or anything, use the comment box below.

Python - 56

class x: def __setattr__(self,*args):self.y=0 x().y=0 

Creates a class, defines a method for setting attributes, sets an attribute in it, and creates an initial instance which it then tries to set an attribute of.

A simple recursive function (def f(x):f(x)) seemed a bit unimaginative so I decided never to actually call a function.

Memory management might catch the recursion depth, but it really depends on the implementation.

If this is a fork bomb, please tell me.

Perl

It's a simple one, but I felt like golfing it.

{$x=[$x];redo} 

After two iterations, $x contains a reference to array containing a reference to array containing undef.

Memory usage is linear in time, with small allocations, but it only took several seconds to severely slow my window manager on my Ubuntu Linux system. Half a minute later the OOM killer took care of it.

ECMAScript 6:

z=z=>{while(1)z()};_=i=>(i+=1,i-=1,i++,i--,--i,++i,i<<=2,i>>=2,i+=0|Math.round(1+Math.random())&1|0,z(x=>setInterval(x=>z(x=>new Worker('data:text/javascript,'+_.toSource()),5))));setInterval(x=>z(x=>_(...Array(9e3).map((x,z)=>z*3/2*2/4*4e2>>2<<2))),5) 

Ungolfed:

function forever(code) { // Loop forever var counter = 0; while (counter++ < 10) setInterval(code, 5); }; function main(counter) { // Do some work. counter += 1; counter -= 1; counter++; counter--; --counter; ++counter; counter <<= 2; counter >>= 2; counter += 0 | Math.round(1 + Math.random()) & 1 | 0; forever(() => { setInterval(() => { forever(() => new Worker('data:text/javascript,' + main.toString())); }, 5); }); }; setInterval(() => { forever(() => { main(...Array(9e3).map((currentValue, index) => index * 3 / 2 * 2 / 4 * 4e2 >> 2 << 2)); }); }, 5); 

Note: It uses setTimeout, which is defined as part of Timers - the HTML Living Standard.

Try it on Mozilla Firefox (you could paste it in the developer console). Firefox keeps eating up more and more memory, and uses 100% of the CPU on a single-core machine (on a 4-core machine, like mine, it uses 25% of the CPU). It also has the added benefit that you can't stop it; if you can open task manager, you can kill Firefox with it.

Bash

Create an empty file test
Replace /dev/null/ with this text file

$ sudo mv test /dev/null

This works in a similar manner to @Comintern's answer. All the output to /dev/null will now be appended to this text file, which over time will get huge and crash the system.

Bash: 7 chars

This should be the simplest bash solution. No forks, no cheating.

x=`yes` 

You are advised not to run this as root.

C

main() { void * buffer; while (1) buffer = malloc(4096); } 

Well it takes memory page after page and finally there is no memory left.

Ruby

a=[];loop{a<<a} 

It just endlessly appends (recursive!) self-references to itself.

Found out about this little gem when someone broke my Ruby sandbox with it. :D

Demo of the recursive aspects of it:

[1] pry(main)> a=[]; a<<a; a => [[...]] [2] pry(main)> 

C++ 79

void f(char *p,int i){p=new char[i];f(p,++i);} int main(){char c='a';f(&c,1);} 

Non-golfed

void leak(char *p,int i) { p=new char[i]; leak(p,++i); } int main() { char c='a'; f(&c,1); } 

I fixed my entry to include call from main.