   Filling up all memory
  I'm trying to test my software in a situation where the PC has no memory left to see what happens.Note: I'm using a LINUX PC (ubunutu).I tried writing a program that essentially does:v1 : while (1) malloc(rand())But the OS/compiler/something just optimizes this away, and it allocates no memory.So I wrote a different version:v2 : while (1) buf = malloc(rand) if (buf) loop:buf=somethingThis now uses all the memory up, but then my program segfaults.Does anyone have a simple test program that will use up all the memory in the system, but then not crash?Thanks!
  Where does it segfault? Within your test loop, within malloc, or in your app?   ;  Are you 100% positive that you're not accidentally writing behind the buffer?   ;  I don't know where it segfaults.This is the complete code I have atm:#include <memory.h>#include <stdio.h>#include <stdlib.h>#include <unistd.h>int main(int argc, char *argv[]) {    int i;    int m;    int tm;    int c;    int *buf;    tm =0;    c =0;    while (1) {   m = rand()*3+10;   buf = (int *)malloc(m);   if (buf==0)  goto end;   buf [0] = rand();   for (i=1;i<m>>1;i++)  buf = i*3;   tm+=m;   c++;   printf("lost %d MB ram\n",tm/(1024*1024));    }end:    while (1) {   printf("i am dead with %d used\n",tm);   usleep(1000);    }}The program never prints anything. It runs, then when it gets to around 90% of memory used it just segfaults and thats it.[Edited by - Zahlman on June 12, 2009 11:44:26 PM];  You're allocating m bytes of memory, but you're trying to write m>>1 ints into it. If your int is say... 4 bytes long, you run into trouble.Also, try to avoid gotos, you could use a break just as easily in this example.   ;  1) Allocating all the memory in the world isn't going to do crap if you have 2 seperate programs. The OS will give each program its own little (4Gb on a 32bit system) bit of virtual memory to play with. Thusly, if both programs aren't actually using the memory all the time, one will get put on disk while the other one uses your actual RAM.2) If you are just trying to use up all the memory for your process, why not just overload new/delete  malloc/free with your own versions.That gives you the chance to just start failing allocations after X Mb have been allocated.Or better yet, use an already made one (the fluid studio's one is better than nothing for a start) and set it to randomly fail allocations.;  Thanks tori, that was the problem! Wasn't thinking clearly.KulSeran:1. But won't I just eat up all the virtual memory, and then effectively the system is out of memory as a whole?2. The problem is the program is written in python/c/c++ so I'm not sure how to adjust your proposal to suit python, etc.   ;  Nope. The system has for all intents and purposes infinite virtual memory(wiki).The limit is a combination of physical ram, hard drive swap space, and virtual address space usage.Each process gets a unique virtual address space with the full amount free (minus memory mapped system resources and libraries).Filling one process' virtual address space, in general, has zero to no effect on any other process' address space.The OS is free to move things from memory to disk and back. The OS is free to not even give your malloc consideration until you actually start writing/reading that memory. The OS is free to compress your memory, ship it off over the network, store it in an offshore database and wait for you to ask for it (well, assuming you set it up to do that).  The point is that every program lives in a happy little island that has very little to do with the actual layout of memory or hardware. Your program has a pointer "0x00000000FF998855" where you store the value 6.  I have a program that also contains the pointer "0x00000000FF998855" and I'm storing the start of a JPG image there.  I can't see you, you can't see me, and we both think we have a 64bit address space all to ourselves.Now, if you write a program that allocates all the ram it can, and then just stits there shuffling bits around randomly in that memory, THEN you will start to see one effect on the system: general slowness.  By randomly asking for memory pages to read and write your program is telling the OS to shuffle data into main RAM so it can be worked on. If you are using a LOT of ram, you can in effect cause the OS to push other processes memory onto the swap. Then when they try to run, they have to wait while the OS puts their data in ram and some of your memory hogging program's data on disk.  But generally, your full address space still isn't keeping other programs from allocating more memory. It just thrashes the active ram the OS is trying to keep around so everything runs smooth.*edit. "intensive purposes" is NOT the saying.... *bash head into wall* "intents and purposes"[Edited by - KulSeran on June 12, 2009 2:32:42 AM];  This is not something you actually need to try, as the internet is full with angry Linux users who are complaining about what will happen. Whether it's really good or bad is debatable :-)Linux will give you any amount of memory you ask for and will pretend everything is good. Many applications don't need all the RAM they ask for, so often things indeed are good.However, there obviously is a hard limit of memory pages (physical RAM and swap space). As long as you (and any other processes) never access more pages than physically exist, no bad things happen.Once you access one page more than the hard limit, the "OOM killer" will kill a more or less random process, which may lead to ... undesirable effects. There has been much flame about this behaviour, and at least two different proposals have been made to protect certain processes from being killed by writing some magic values to some place in /proc, but I'm not aware of an official, well-documented solution.   ;  Thanks for your input KulSeran, but I did indeed find that the system responded exactly the way samoth explained it.Essentially, when the hard drive is full, and then I run the memory-consuming program, at some point the system kills a process and then everything seems to come to a grinding hault. I guess if the rest of the code is written well it should continue to run as long as it is not the process that gets killed. Thanks everyone for your help.   