ActionScript has an underlying design flaw in its memory management. This behaves differently depending on the machine. On Windows it roughly craps out at 1.25GB, while even a 32bit OS can handle more. Especially vulnerable are the Sound, ByteArray and FileStream classes, but others using these in the background are effected, too.
I learned that when dealing with lots of files (FileStream) and manipulating them (ByteArray). The error messages thrown when the memory limit is reached are however mostly not pointing to the correct source of the error... after writing a wrapper and a custom debugger for the FileStream class to handle all the oddities it has (try files with 0 bytes length, a favorite source of errors) I came down with 4k lines of code, but still couldn't get all cases under control.
I stumbled over these errors in almost any memory intensive AIR application I made and eventually decided to quit ActionScript. The underlying issue must be known to Adobe since at least 2009. Remember when FP9 broke the unloadSound() method and Adobe promised to fix it in FP10? Well, they somewhat fixed it, it would now happen less often. But that's about it. They didn't fix the underlying problem entirely.
So, a 64bit version of AIR won't help you unless Adobe fixes the bugs in the underlying architecture. And the way they handled ActionScript in the last years, I wouldn't bet on them doing that.
This is the function that finally made me realize what's going on. Run it and step through the while loop and watch what happens to the res variable after res.length == 18.
public static function hexToString(hex:*, len:uint = 32):String
{
if (hex == null || isNaN(hex))
{
return "UNKNOWN TYPE";
}
var str:String = '';
var strIn:String = hex.toString(16).substr(-len).toUpperCase();
var char:uint = 0x00;
var charStr:String = '';
var res:String = '';
while (strIn.length < len)
{
strIn = '0'+strIn;
}
res = strIn;
while (res.length > 1)
{
charStr = '0x'+res.substr(0, 2);
char = parseInt(charStr, 16);
res = res.substr(2);
str += String.fromCharCode(char);
}
return str;
}
I converted the function to PHP and JS to confirm and neither PHP nor JS showed erroneous behavior.
