bug一年半只出现一次的时间2015-10-13我负责的一个用C写的业务流程崩溃了。我用gdb查看了coredump文件，发现是在反序列化业务包。,在序列化库中崩溃。当时怀疑是业务包有问题，但也不能排除是业务进程踩内存的可能，因为后来的crash并没有再次发生，排查方法也不多当时，所以我没有深入研究这个错误。2017-04-27这个业务崩溃了两次，和2015-10-13是同一个stack。“死亡场景”进程使用gdb查看coredump文件，发现在反序列化解析过程中解析失败，然后跳转到cleanup逻辑。在释放数组内存时，它引用了一个空指针并导致崩溃。库代码已发布内存中没有空指针检查。在排查过程中，目前还不能完全排除是业务进程踩内存导致业务包异常的问题，但是相比2015-10-13，我们增加了一个request和响应审计数据，会记录客户端所有的请求和响应的数据，通过这个数据审计查看工具，发现问题对应的业务请求确实有问题，那么我们就可以确认bug是由于客户端，而不是踩到内存的业务流程。Fixtheproblem修改代码，释放反序列化库空间，增加对上层空指针的检查，避免服务器收到问题请求后崩溃，导致业务中断。将现象和数据反馈给客户，让客户排查问题。考虑到任何系统做大后，业务数据都会经过很多环节和系统，问题排查难度大。平时需要对业务请求的全路径进行监控和记录，这样在排查问题的时候才能事半功倍。
