热烈庆祝终于开写一篇Blog文章!

我实在确实是太懒了！为了摆脱这种状态,决定每天在CDSN上至少写一篇文章！决心是蛮大的，呵呵，预祝07年可以实现。

为了不扫大家的兴，只好找点技术方面的事说说。前几天测试部刚提了一个问题单，很变态的测法，终于把我的服务弄coredump，实在是强人！因为该服务已经在多个局点运行很久，经过N轮的测试，而且已经在多个R版本运行很稳定，居然又被他弄COREDUMP了。值得各位搞测试的同胞们看看。

公司由于信息安全无法将相关信息传出来，简要描述一下：偶的服务，完全依赖另一个FM服务，蜡笔小新（该测试强人）使用监控管理服务的GUI和命令行反复重启、KILL各服务，高强度并行的这样乱搞，然后跑到CORE目录下一看，居然产生了coredump文件。他自己都不知道做哪些操作时产生的。

从堆栈上看到CORE在了第三方库SNMP++里的Mib::construct函数里，基本上不可能是使用SNMP++中的问题。而从CORE文件以及SNMP++源码看到发生COREDUMP的语句只有可能是由于空指针引发SIGSEGV信号，而不是core文件中显示的SIGBUS信号。分析TRACE估计是SnmpAgent启动过程中FM被杀死导致启动失败，退出时没有完全释放资源，进程再次启动后内存混乱导致。由于我目前已不负责解决问题单，也没代码和编译环境，就将问题丢给印度人。结果两天了他们还没任何头绪，老大已经开始催版本了，只好拿来自己分析。结果测试部居然已经把环境干掉，现在只有stack，连core文件也没有了，真是死无对证and欲哭无泪！非常郁闷的走读代码，没有发现问题，已经预备要跑PURIFY了，居然被我找到重现条件，与估计一致，就是杀FM进程的时机要掌握好。当启动失败后进程里的东西不太对劲，导致下一次启动COREDUMP！哈哈，非常高兴的跑回家，明早铁定可以搞定了。

OK，终于搞定第一文！跑把卡丁车（迈入L3专业级别不久，哈哈）爽一下。