Or... how to kill a user's computer with 1 line of ActionScript.

I've been profiling CPU/RAM usage in Flash 8 content in the last few days in preparation for the Flash 8 Bootcamp I'm running in Toronto and LA. Last night I ran into a major memory leak that is wreaking havoc with some of my latest experiments, and this morning I isolated it. This leak makes it ridiculously easy to accidently create a process that increases the Flash Player's memory heap at a very rapid rate, and ultimately immobilizes the user's system (I've had to do a few slow motion restarts while testing this - I had over 15GB of virtual memory dedicated to the player at one point).

The problem is simple: The Flash Player does not ever dispose of BitmapData objects stored in function variables. This is easily reproduced by placing the following line of code in the timeline of a new FLA: 

function onEnterFrame() { var foo = new flash.display.BitmapData(500,500); }
Run it and watch the memory usage. It will increase by around 60MB per second. This is because the variable foo is not disposed of when the function finishes executing. As such, the BitmapData object remains in memory until you close the player. To clarify this (in response to a comment below), function variables are transitory - they should only exist during execution of the function. The Flash Player should always mark all function variables for deletion as soon as the function finishes executing. This occurs with other variable types, but does not appear to be working properly with BitmapData objects.

In many scenarios, you can avoid this problem by using BitmapData.dispose to explicitly remove your bitmaps from memory. 

function onEnterFrame() {
     var foo = new flash.display.BitmapData(500,500);
     foo.noise(1);
     foo.dispose();
}
This does not work if you want to attach or return the bitmap however, because dispose deletes the actual bitmap data in memory, not just the reference. 
function onEnterFrame() {
     var foo = new flash.display.BitmapData(500,500);
     foo.noise(1);
     mc.attachBitmap(foo,1);
     foo.dispose();
     // The bitmap will not be show up because it no longer exists
}
There are two obvious ways to work around this, which can be a little messy, but work in almost all scenarios. The first approach is to always reuse bitmaps. This is more efficient anyway, because bitmaps are expensive to instantiate and destroy, but it isn't always possible or desirable. 
foo = new flash.display.BitmapData(500,500);
function onEnterFrame() {
     // reuse foo:
     foo.noise(1);
     mc.attachBitmap(foo,1);
}
The second way is to hold on to a reference to the bitmap, so that you can dispose of it later. 
foo = null;
function onEnterFrame() {
     // dispose of the old bitmap:
     foo.dispose();
     foo = new flash.display.BitmapData(500,500);
     mc.attachBitmap(foo,1);
}
It is also important to remember to dispose of any interim bitmaps you use for calculations. 
function displaceStuff(p_bmp) {
     var mapBmp = new flash.display.BitmapData(500,500);
     // do stuff
     mapBmp.dispose();
     return p_bmp;
}
I hope this helps you avoid this problem for the time being, and hopefully Macromedia releases a FP8.1 update at some point to fix this dangerous issue. The last thing we need is for Flash to drop its reputation for being a toy to build intro animations and pick up a reputation for crashing user's systems instead.

Update: I'm continuing to look into this, it's interesting to note that the bitmaps are not cleaned up even if placed into an object in a function var. This does appear to only occur with BitmapData objects - I've tested the same scenario with large arrays, and the memory heap never increases. I've also tested to ensure that BitmapData objects are properly disposed in other situations, and it appears they are cleaned up when all references are removed. Stranger and stranger.