最近在忙着做某公司的一个项目，临近测试节点，闲着没事，在那来回重启设备，结果发现，带流带配置重启了几次以后，会偶然出现某个进程重启的问题，进而导致这个进程下的所有业务功能都不可用，这下麻烦大了，临近测试了啊，没办法，只能周末加班突击解决了。
问题出现的时候，没有任何调用栈信息被保存，从死机文件里面也得不到有效的异常信息。只能看到killed by signal 11，si code 2，除此之外就没有其它的有效信息了。只能分析这个信息，signal 11，很容易知道这是一个出现了内存错误的问题，一般出现内存被踩，或者空指针的时候，经常会见到。而si code 2，表示退出码是2，也就是说有可能是触发了exit(2)类似的函数调用。
于是，只能先从代码入手，从上到下开始排查代码，并且很幸运的找到了类似的代码段。但是是在系统底层的函数调用，和我们的业务应该是不相关的。于是只能采用最原始的方法，挂gdb，设置断点，在进程重启的时候断住，但是由于问题不是必现的，所有只能不停的试，终于在重启了设备n次以后，gdb断在了业务的某个处理流程中，并且精确的打印出了出问题的代码行，经过仔细分析发现，原来是某个入参超过了数组的最大下标，导致数组越界。唉，C语言的大坑，仔细检查了代码，发现还有一个类似的错误，仔细修改并重新检查了代码以后，终于解决了这个重大的隐患。
这给我提了个醒，以后写代码的时候，除了保证语法功能没问题外，还要注重数组的边界检查，重要的是，要注重测试。
网友评论