Flash进行资源加载时常会“停住”，表现为加载进度卡在某个地方。跟踪发现Loader的progress为100%，但未发送Event.COMPLETE或IOErrorEvent.IO_ERROR等事件。

目前项目加载底层的队列依赖于Loader（URLLoader）的COMPLETE和ERROR事件，如果这两个事件不发送将导整套加载机制崩溃 - -，后续跟踪发现的确会如此。

问题展示

- 阅读剩余部分 -

Error #2044: 未处理的 securityError:。 text=Error #2048: 安全沙箱冲突:c.dou.li:4000/demo.swf 不能从 s.dou.li:10000 加载数据。

Flash客户端demo.swf以Socket连接s.dou.li:10000地址时报如上异常，最被怀疑为s.dou.li未对demo.swf进行授权，未返回安全策略文件。

client尝试开启一个socket时，Flash会先启动一socket发送“<policy-file-request/>\0”串给server；

服务端收到后返回“<cross-domain-policy> <allow-access-from domain=\"*\" to-ports=\"*\"/></cross-domain-policy> \0”内容表示对所以客户端授权；

以上都没问题，且直接复用上一项目的结构，经过查看大量资料后确定策略文件的请求、返回、内容没问题。

继续怀疑client的socket初始化参数有问题，查了一下Socket的timeout设置，次奥~~~~值为20，超时时间20ms啊，太低级了有木有。果断将timeout改为30000问题解决。

项目底层资源Cache超时使用了Timer驱动，每个资源到期Cache超时时会进行“释放”。后来发现有明显内存泄漏，排查出是因为Timer未进行导致。Oh，卖糕的~

ResourceManager为单例，Timer在工程启动时开始执行，为了方便说明见如下示例：

    public class Demo extends Sprite{
        private var _t:Timer;

        public function Demo(){
            _t = new Timer(500);
            _t.addEventListener(TimerEvent.TIMER, onTimer);
            _t.addEventListener(TimerEvent.TIMER_COMPLETE, onComplete);
            _t.start();
            trace("is running:" + _t.running);
        }

        private function onTimer(e:Event):void
        {
            trace("timer");
        }

        private function onComplete(e:Event):void
        {
            trace("complete");
        }
    }

输出：
is running:true

以上结果应该在意料之中？

但，只打印了这一行，onTimer()和onComplete()中的trace()未执行，问题就出在这。正常情况应该至少会每500ms打印一次“timer”。

若增加一个ENTER_FRAME监听，每帧输出Timer的状态，如下：

- 阅读剩余部分 -

用mxmlc编译AS3工程时报了个异常：

Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object

怀疑是jre安装有问题，制裁重装java1.7老问题解决，出现新异常：

Error loading: C:\Program Files\Java\jre7\bin\client\jvm.dll

再次重装jre问题依旧，后上网找了一下发现是因为windows/system32/msvcr100.dll文件缺失，放入msvcr100.dll问题解决。

把msvcr100.dll文件附上

msvcr100.dll.zip (403.6 KB, 下载次数: 1637, 最后修改: 2014-01-07 23:33)

最近用CURL进行FTP上传时老报异常：curl:(9) Server denied you to change to the given directory，在不同的FTP Server环境测试不100%重现。

观察后发现，当登录FTP Server时默认进的是根目录则没问题，否则会出上述异常，如：

FTP Server的根目录为“/data/ftp/”，其中有子目录“/data/ftp/demo/aaa/”。现在要上传文件d:/a.zip到 aaa目录，则CURL命令为：

curl -T d:/a.zip ftp://username:password@domain:21/demo/aaa/
如果登录FTP的默认路径为根/时正常上传；
如果登录FTP的默认路径为/demo/时会报“curl:(9) Server denied you to change to the given director”异常；

太蛋疼了这应该是CURL的一个Bug，CURL在解析FTP路径时会默认认为登录的是FTP Server的根目录，根据命令的路径查找后得出结果为“/data/ftp/demo/demo/aaa”所以异常。

解决方案有二：

1. 根据以上分析CURL的路径解析规则，当默认登录目录为/data/ftp/demo/时使用命令“curl -T d:/a.zip ftp://username:password@domain:21/aaa/”，命令中去掉demo目录，解析后的路径就是正确的了；

2. 修改CURL的源代码，自己重新编一个库，对大多数人来说这代价太高，有兴趣的朋友可以尝试一下，具体修改方案可参考（http://blog.csdn.net/langeldep/article/details/6166218）