WARNING! Do not run this program without reading this text down to the end. It may render your system unusable for a limited amount of time or force you to reboot using the Big Red Button. This is not a joke. You have been warned. Dear judges, in case this entry wins an award and is published I request you to put the above warning in a comment at the top of the source so that curious hot shots who do not see these remarks are warned. Thank you. Why I think my entry is obfuscated ---------------------------------- There are some layout obfuscations that hinder readability, like some (but not all) one character tokes in column 1. Includes, defines and declarations of data and functions appear intermixed. iso646.h is even included in the middle of an expression, how disgusting. Besides, requiring iso646.h will render the program uncompilable on many systems that have not yet incorporated Amendmend One to The Standard. If you, dear reader, suffer from this disease, just cat <<'-end-of-silly-header' >/usr/include/iso646.h /* Macros for C programs written in national variants of ISO 646. */ #define and && #define and_eq &= #define bitand & #define bitor | #define compl ~ #define not ! #define not_eq != #define or || #define or_eq |= #define xor ^ #define xor_eq ^= end-of-silly-header There are no `if' statements. They have been replaced by "switch () case 1:" or "switch () case 0:" etc. At least one switch has a declaration after the opening brace, booh! Identifiers are named after random programming languages, Basic, Cobol, F77, awk etc. You have to select maximum ANSI C conformance of your compiler. The source fails to compile under a C++ compiler due to the `new' identifier which is a C++ reserved word: % g++ prog.c prog.c:9: parse error before `new' prog.c:16: parse error before `new' prog.c:46: parse error before `void' prog.c:65: parse error before `Lisp' prog.c:68: parse error before `;' [...] prog.c:91: confused by earlier errors, bailing out The source fails to compile on compilers that recognize the inline keyword by default, e.g. gcc: % gcc prog.c prog.c:46: parse error before `void' prog.c: In function `main': prog.c:91: parse error before `inline' prog.c: At top level: prog.c:97: parse error before `void' The -ansi option to gcc fixes this. The source fails to compile on obsolete systems with obsolete memory models due to the identifier `far' (to be honest: this is untested :-). Does your indent cope with backslash/newline pairs inbetween keywords like in "re\turn"? Solaris' indent inserts spaces and thereby renders the source uncompilable... The indented source will exhibit different semantics when indenting changes the number of lines (due to using the __LINE__ macro in an expression). sizeof __TIME__, this one's for the philosophers and physicists among us programmers. What is it? sizeof (char *) -- no. Strlen ("hh:mm:ss")? -- no. It's the same as sizeof __DATE__ - sizeof "no" :-) The program is POSIX conformant and lints without warning under Solaris' Sunpro lint. Allocated memory is correctly freed on all possible execution paths. What this program does ---------------------- This program tests your operating system's allocation honesty. It forks a child that will allocate as much as possible with byte granularity and then write to every 1024th byte, at the same time writing a status report on stdout. This way each page of the allocated virtual memory will eventually be referenced. Without any arguments, malloc() will be used to allocate memory. If the first arg starts with c, calloc() will be used instead. I distinguish three different behaviours: 1) OS without memory overcommit: malloc does not lie -- you can use all memory the OS granted to you. 2) OS with memory overcommit: malloc lies -- any program may get killed at random when the OS can not acquire a free page. 3) OS with pseudo memory overcommit: malloc lies -- The OS puts processes to sleep for which it can not acquire a free page. Because other processes are also affected this way, the system slows down and quickly becomes totally unusable (also known as "thrashing"). Because more and more processes wait for memory returned by other exiting processes the system eventually enters a deadlock situation and effectively halts. I had the pleasure and pain to find all three behaviours on the platforms I use regularly. What follows are the outputs for Solaris, FreeBSD and Linux. The Linux case is interesting in that the behaviour changes when calloc is used instead of malloc. ***** SOLARIS 2.5 (sparc): % prog Trying to malloc 2048M+0K+0 bytes..nope Trying to malloc 1024M+0K+0 bytes..nope Trying to malloc 512M+0K+0 bytes..nope Trying to malloc 256M+0K+0 bytes..nope Trying to malloc 128M+0K+0 bytes..YEP Trying to malloc 192M+0K+0 bytes..nope Trying to malloc 160M+0K+0 bytes..YEP Trying to malloc 176M+0K+0 bytes..nope Trying to malloc 168M+0K+0 bytes..YEP Trying to malloc 172M+0K+0 bytes..nope Trying to malloc 170M+0K+0 bytes..YEP Trying to malloc 171M+0K+0 bytes..YEP Trying to malloc 171M+512K+0 bytes..YEP Trying to malloc 171M+768K+0 bytes..nope Trying to malloc 171M+640K+0 bytes..nope Trying to malloc 171M+576K+0 bytes..YEP Trying to malloc 171M+608K+0 bytes..YEP Trying to malloc 171M+624K+0 bytes..nope Trying to malloc 171M+616K+0 bytes..nope Trying to malloc 171M+612K+0 bytes..YEP Trying to malloc 171M+614K+0 bytes..YEP Trying to malloc 171M+615K+0 bytes..YEP Trying to malloc 171M+615K+512 bytes..YEP Trying to malloc 171M+615K+768 bytes..YEP Trying to malloc 171M+615K+896 bytes..YEP Trying to malloc 171M+615K+960 bytes..YEP Trying to malloc 171M+615K+992 bytes..YEP Trying to malloc 171M+615K+1008 bytes..YEP Trying to malloc 171M+615K+1016 bytes..nope Trying to malloc 171M+615K+1012 bytes..nope Trying to malloc 171M+615K+1010 bytes..nope Trying to malloc 171M+615K+1009 bytes..nope Able to malloc 171M+615K+1008 bytes 1 kilo bytes ok 2 kilo bytes ok ... 175719 kilo bytes ok no overcommit ***** FreeBSD 2.1 (i386) % prog Trying to malloc 2048M+0K+0 bytes..nope Trying to malloc 1024M+0K+0 bytes..nope Trying to malloc 512M+0K+0 bytes..nope Trying to malloc 256M+0K+0 bytes..nope Trying to malloc 128M+0K+0 bytes..nope Trying to malloc 64M+0K+0 bytes..nope Trying to malloc 32M+0K+0 bytes..YEP Trying to malloc 48M+0K+0 bytes..nope Trying to malloc 40M+0K+0 bytes..nope Trying to malloc 36M+0K+0 bytes..nope Trying to malloc 34M+0K+0 bytes..nope Trying to malloc 33M+0K+0 bytes..nope Trying to malloc 32M+512K+0 bytes..nope Trying to malloc 32M+256K+0 bytes..nope Trying to malloc 32M+128K+0 bytes..nope Trying to malloc 32M+64K+0 bytes..nope Trying to malloc 32M+32K+0 bytes..nope Trying to malloc 32M+16K+0 bytes..nope Trying to malloc 32M+8K+0 bytes..nope Trying to malloc 32M+4K+0 bytes..nope Trying to malloc 32M+2K+0 bytes..YEP Trying to malloc 32M+3K+0 bytes..YEP Trying to malloc 32M+3K+512 bytes..YEP Trying to malloc 32M+3K+768 bytes..YEP Trying to malloc 32M+3K+896 bytes..YEP Trying to malloc 32M+3K+960 bytes..YEP Trying to malloc 32M+3K+992 bytes..YEP Trying to malloc 32M+3K+1008 bytes..YEP Trying to malloc 32M+3K+1016 bytes..YEP Trying to malloc 32M+3K+1020 bytes..YEP Trying to malloc 32M+3K+1022 bytes..nope Trying to malloc 32M+3K+1021 bytes..nope Able to malloc 32M+3K+1020 bytes 1 kilo bytes ok ... 21668 kilo bytes ok malloc lied! Killed by SIGKILL Nov 24 18:11:56 /kernel: swap_pager: out of space Nov 24 18:11:57 /kernel: Process 5 killed by vm_fault -- out of swap % prog c Trying to calloc 2048M+0K+0 bytes..nope Trying to calloc 1024M+0K+0 bytes..nope Trying to calloc 512M+0K+0 bytes..nope Trying to calloc 256M+0K+0 bytes..nope Trying to calloc 128M+0K+0 bytes..nope Trying to calloc 64M+0K+0 bytes..nope Trying to calloc 32M+0K+0 bytes calloc lied! Killed by SIGKILL Nov 24 18:14:54 /kernel: swap_pager: out of space Nov 24 18:14:55 /kernel: Process 7 killed by vm_fault -- out of swap ***** Linux 1.2.13 (i386) % prog Trying to malloc 2048M+0K+0 bytes..nope Trying to malloc 1024M+0K+0 bytes..nope Trying to malloc 512M+0K+0 bytes..nope Trying to malloc 256M+0K+0 bytes..nope Trying to malloc 128M+0K+0 bytes..nope Trying to malloc 64M+0K+0 bytes..nope Trying to malloc 32M+0K+0 bytes..nope Trying to malloc 16M+0K+0 bytes..YEP Trying to malloc 24M+0K+0 bytes..nope Trying to malloc 20M+0K+0 bytes..YEP Trying to malloc 22M+0K+0 bytes..YEP Trying to malloc 23M+0K+0 bytes..YEP Trying to malloc 23M+512K+0 bytes..YEP Trying to malloc 23M+768K+0 bytes..YEP Trying to malloc 23M+896K+0 bytes..YEP Trying to malloc 23M+960K+0 bytes..YEP Trying to malloc 23M+992K+0 bytes..YEP Trying to malloc 23M+1008K+0 bytes..YEP Trying to malloc 23M+1016K+0 bytes..YEP Trying to malloc 23M+1020K+0 bytes..YEP Trying to malloc 23M+1022K+0 bytes..YEP Trying to malloc 23M+1023K+0 bytes..YEP Trying to malloc 23M+1023K+512 bytes..YEP Trying to malloc 23M+1023K+768 bytes..YEP Trying to malloc 23M+1023K+896 bytes..YEP Trying to malloc 23M+1023K+960 bytes..YEP Trying to malloc 23M+1023K+992 bytes..YEP Trying to malloc 23M+1023K+1008 bytes..YEP Trying to malloc 23M+1023K+1016 bytes..YEP Trying to malloc 23M+1023K+1020 bytes..YEP Trying to malloc 23M+1023K+1022 bytes..YEP Trying to malloc 23M+1023K+1023 bytes..YEP Able to malloc 23M+1023K+1023 bytes 23294 kilo bytes ok malloc lied! Thrashing % prog c Trying to calloc 2048M+0K+0 bytes..nope Trying to calloc 1024M+0K+0 bytes..nope Trying to calloc 512M+0K+0 bytes..nope Trying to calloc 256M+0K+0 bytes..nope Trying to calloc 128M+0K+0 bytes..nope Trying to calloc 64M+0K+0 bytes..nope Trying to calloc 32M+0K+0 bytes..nope Trying to calloc 16M+0K+0 bytes..YEP Trying to calloc 24M+0K+0 bytes..nope Trying to calloc 20M+0K+0 bytes..nope Trying to calloc 18M+0K+0 bytes..nope Trying to calloc 17M+0K+0 bytes..nope Trying to calloc 16M+512K+0 bytes..nope Trying to calloc 16M+256K+0 bytes..nope Trying to calloc 16M+128K+0 bytes..nope Trying to calloc 16M+64K+0 bytes..nope Trying to calloc 16M+32K+0 bytes..nope Trying to calloc 16M+16K+0 bytes..nope Trying to calloc 16M+8K+0 bytes..YEP Trying to calloc 16M+12K+0 bytes..YEP Trying to calloc 16M+14K+0 bytes..nope Trying to calloc 16M+13K+0 bytes..nope Trying to calloc 16M+12K+512 bytes..nope Trying to calloc 16M+12K+256 bytes..nope Trying to calloc 16M+12K+128 bytes..nope Trying to calloc 16M+12K+64 bytes..nope Trying to calloc 16M+12K+32 bytes..nope Trying to calloc 16M+12K+16 bytes..nope Trying to calloc 16M+12K+8 bytes..nope Trying to calloc 16M+12K+4 bytes..nope Trying to calloc 16M+12K+2 bytes..nope Trying to calloc 16M+12K+1 bytes..nope Able to calloc 16M+12K+0 bytes 1 kilo bytes ok ... 16396 kilo bytes ok no overcommit Implementation remarks ---------------------- How can we distinguish the three different OS types from the table above? Obviously, type 1), no overcommit, is easy. For type 2), random kill, we need to fork a child that can be killed and whose exit status the parent collects and decodes. Here's where POSIX enters the scene. Type 3), thrashing, was the hardest part. The first attempt was to measure the elapsed processor time it takes to write a single byte (using clock()). If a certain threshold is reached I assume the system is thrashing. When thrashing, however, the process does not consume processor time in a noticeable amount any longer and I lose. So I switched to measuring wall clock time using time(). On the one system that I observe thrashing (Linux) this works (although the value returned by time seems to 'hang' sometimes when the OS thrashes. Exceeding a threshold of 5 seconds may be detected only after half a minute or so.