bug出现的时间点
- 2015-10-13 我负责的一个使用c写的业务进程奔溃，使用gdb查看coredump文件发现是在对业务包做反序列化的时候，在序列化库里崩溃了。
- 当时怀疑是业务包有问题，但也不能排除业务进程踩内存的可能，因为后续这个奔溃也再没出现，且哪个时候排查手段也不多，故没有深入去排查这个bug。
- 2017-04-27 这个业务奔溃了两次和2015-10-13是一样的堆栈。
进程“死亡现场”
使用gdb细看coredump文件发现是在反序列化解析过程中解析失败然后跳到清理逻辑，在释放一个数组内存的时候引用的了空指针从而导致的奔溃，库代码在释放内存时没做空指针校验。
排查过程
这个时候还是不能完全排除业务进程踩内存导致业务包异常的问题，但是相比2015-10-13日我们已经添加了一个请求和应答稽核数据，这个数据会记录客户端所有的请求和应答数据，通过这个数据稽核查看工具发现对应有问题的业务请求的确是有问题的，那么这时我们可以确认这个bug是由客户端导致的，而不是业务进程踩了内存。
修复问题
- 修改反序列化库中释放空间的代码，添加上空指针的检查，规避服务端收到问题请求崩溃问题，从而导致业务中断。
- 把现象和数据反馈给客户端，让客户端去排查问题。
思考
任何系统做大之后，业务数据都会通过很多环节和系统，出现问题很难排查，通常很有必要对业务请求做全路径的监控和记录，这样查问题时才能事半功倍。
