Killing a Mac OS X machine

My buddy Robert Citek has been interested, over the last couple of years, in ways to kill Unix machines. In other words, he tries to create scripts that will bring *nix machines to their knees. His interest isn’t malicious - he’s one of the most honest guys I know - but he thinks that by understanding where the weaknesses are, it will better enable him to shore those up and turn weaknesses into strengths. Robert knows Linux really, really, really well (actually, he knows RPM-based distros really well; Debian-based distros are still something new to him), but he bought a Mac OS X laptop a year ago, so now he’s focusing on ways to kill Mac OS X (which is still Unix, remember). Here’s his latest report, from the CWE-LUG mailing list:

<Robert’s email>

I was able to successfully kill my Mac last night with the following script [Scott: remove the blank lines from the script; this blog’s wysiwyg keeps inserting them]:

perl -le '


   @foo=qw(hello) ;


   for (my $i ; $i<100 ; $i++) {


     push(@foo, @foo) || die "$i -- no more\n" ;


     print "$i" ;


   } ;


   print "size is $#foo" ;


'

By killed I mean that without warning the Mac just turned off. When I powered on, it took a long time (probably doing an fsck) and then the time was set to January 1970. So, this was the hardest crash I have ever seen on a Unix box.

So I figured this script would be a good test for ulimit (bash, ksh ; limit in tcsh, csh). But no matter what setting I used for the various ulimit options, the script kept running, sucking up more and more RAM, until I manually stopped it with a Ctrl-C.

I’m curious to know if the above script kills anyone else’s machines and if setting ulimit/limit options prevents it?

</Robert’s email>

Jon, another member of the CWE-LUG list, is a big FreeBSD user, and he reported that the script did nothing on his FreeBSD box. It ran for 10 seconds or so & things slowed down, but then a warning appeared in the terminal - “Out of memory during request for 1012 bytes, total sbrk() is 535257088 bytes” - and things resumed as normal! On OpenBSD, the script ran for 4 seconds, maybe, and then gave an “Out of Memory” error, but there was no slowdown in performance.

What about the rest of you out there? Try it - ON A NON-PRODUCTION MACHINE!!! - & let us know!

View Tags

My buddy Robert Citek has been interested, over the last couple of years, in ways to kill Unix machines. In other words, he tries to...

Add a Comment

Sign in »

19 Comments

Filter by:

Les

Running 10.3.7 on a iBook G3 700 MHz, 6.33 Gb free, I get an out of memory error after 24: *** malloc: vm_allocate(size=1069056) failed (error code=3) *** malloc[597]: error: Can't allocate region Out of memory! Wow! Never had my machine come to that much of a screeching halt and recover. I'm amazed.

February 07 2005 at 12:18 PM Report abuse Permalink rate up rate down Reply

Joe Mullins

His hard crash was most likely caused by a dead battery. The clock reset is a dead giveaway. He was probably already pretty low in processor, and the demands of the script probably kept the low power warning from coming up before the machine died. The only other situation that would cause this is corrupted power manager settings. If he wants to try again, reset the power manager, plug it in and give it a run. I'll bet it won't die.

February 04 2005 at 5:42 PM Report abuse Permalink rate up rate down Reply

TeeJay

Has anyone found a way to fix this problem? *** malloc: vm_allocate(size=8421376) failed (error code=3) What's the way around it? Thanks

January 27 2005 at 5:42 PM Report abuse Permalink rate up rate down Reply

Jean P

Running 10.3.6 on a DP G5 2.0, I get an out of memory error after 24: *** malloc: vm_allocate(size=8421376) failed (error code=3) *** malloc[597]: error: Can't allocate region Out of memory! *** malloc: vm_allocate(size=8421376) failed (error code=3) *** malloc[597]: error: Can't allocate region Out of memory!

January 19 2005 at 10:35 PM Report abuse Permalink rate up rate down Reply

MikeS

A couple of observations: 1) All that this test does is allocate virtual space and dirty it. This forces the system to find pages to back the virtual memory, which it will do by saving their contents to the paging file(s) and then taking them away from whatever was using them before. This "kills" the system because the process is slow, and for the user interface to make any visible progress it must fight to get the pages that were stolen back. 2) The size of the largest object that can be allocated via malloc (which is what Perl is using) is constrained by the layout of the process' virtual address space. Under MacOS X you can use the vmmap command to examine a process' layout. The malloc interface requires contiguous space; an allocation can't be made up of several chunks. 3) The way that allocation is performed by this test tool means that the allocation which fails will be much smaller than the largest allocatable object; the reason being that the previous allocation will be blocking off a large portion of the available space. Consider: Initially, 10 slots empty: [__________] Allocate 1: [o_________] Allocate 2: [xoo_______] Free 1, allocate 4: [_xxoooo___] Free 2, but cannot allocate 8, even though it would have fit to begin with: [___xxxx___] 4) The symptoms described for the powerbook in the first case above are consistent with it overheating. For a portable subjected to extended, nonstop paging activity this isn't too surprising. = Mike

January 19 2005 at 5:49 PM Report abuse Permalink rate up rate down Reply

Gary Bringhurst

I couldn't affect the running of this perl script using ulimit with either the data segment or maximum virtual memory settings in 10.3.7 on my dual G5 1.8ghz. Regardless of what setting I used it blew right past it and kept racking up the virtual memory. This is especially interesting to me because I've found that in 10.3.6 Apple changed memory handling such that users of Strata 3D CX can no longer allocate single large rendering buffers that exceed some new limit (so far around 512meg). I haven't been able to find any documentation on this change either.

January 18 2005 at 7:05 PM Report abuse Permalink rate up rate down Reply

Peter Knapp

I'm currently at 24 and still going. Tested this on a powerbook 1.5ghz with 1.25 gig of ram and Panther 10.3.7. It's still usable...reminds me of my parents win 98 machine. Slow HD etc. Only I still have 15mb ram free hehe. HD commits are huge, but the HD swap file doesn't seem bigger. Expose and the dock are normal. Ah..ended at 24: This error message: *** malloc: vm_allocate(size=1069056) failed (error code=3) *** malloc[1808]: error: Can't allocate region No crash...no problem. I can now go back to my evening! My PB has never got this loud before.

January 17 2005 at 9:10 PM Report abuse Permalink rate up rate down Reply

ZDot

Hi there. This is perhaps partially unrelated, but I tried this on my Toshiba 5200 notebook (P4-M 2.2GHz, 512Mb/RAM, 60Gb HD) running Linux-Mandrake 10, and it made it to 21 before hemorrhaging: "Out of memory!" No hard crash; recovered quite nicely. Z.

January 16 2005 at 6:41 PM Report abuse Permalink rate up rate down Reply

Jean P

For those of you who who got out of memory errors, I would be curious exactly which version of the OS you are running. We are working on an assumption that this bhavior changed in the Mac OS at approximately 10.3.6, and so exact OS version would be helpful. Thanks.

January 16 2005 at 6:36 PM Report abuse Permalink rate up rate down Reply

Jon-d

I found what may be a solution. Here at: A solution for Mac OS X process limits http://www.macosxhints.com/article.php?story=200311151254441 It states (parenthetically) that the user limits are controlled by /etc/rc.common. Here is the the relevant entry, in that file: ####################### # Configure the shell # ####################### ulimit -u 512 Perhaps there is a man page for Mac OS X ? In the shell do: man -k rc.common NOTE: I don't have a Mac; I use OpenBSD as my desktop. Wish I could be of more help.

January 16 2005 at 4:11 PM Report abuse Permalink rate up rate down Reply