makefile文件没写好导致程序core dump的定位经历与反思------又是“协议“不一致产生的core dump

       最近碰到这样一个问题： 原本好好的程序， 经我加一些代码后， 程序就core dump了.

       于是， 我回退代码， 结果就没有core dump了， 我仔细审视了一下自己写的每行代码， 居然没有发现任何疑点， 怪哉

 

       我不太想用二分查找的方法来定位， 粗暴低效， 所以打算依赖于core文件来分析， 万幸的是， 抓到了core文件， 可是用gdb xxx core进行分析的时候， 发现是no stack. 郁闷。

       于是， 看了一下core文件的大小， 发现才5372个字节， 这肯定是core文件被截断了， 所以就查了查unlimit -c的值， 结果是unlimited, 这就纳闷了， 为什么unlimited大小的core限制实际只有5372字节呢？

       于是， 想到了之前某哥说过， 真正的core大小限制要在/proc/pid/limits中查， 结果发现： core的soft阈值是5372， hard阈值是unlimited,  原来如此， 真的是被截断了。

       于是， 找到了系统的配置文件init.xml,  修改soft阈值为unlimited, 重启程序， 重新生成core,  这下core文件就大了很多， 开始有点高兴了。

 

       接着， 拿着core文件分析， gdb xxx core,  然后bt,  出来的信息不太明显， 但仔细看看， 还是能发现了错误的地方(有assign这个字眼)， 几乎可以确定的是： 出错地方是: pmsg->data = data;  这个语句有什么问题呢？ 它是绝对正确无误的啊， 左边右边都是C++ sting类型。

      于是， 将我改的代码回退到只修改两处： 1. 在头文件msg.h中额msg结果提中只增加一个data字段； 2. 在a.cpp中值增加对应的pmsg->data = data;

      结果程序还是core了， 如此简单的两行代码居然能让程序core掉， 纳闷了一段时间。

      于是， 继续回退到只修改头文件msg.h,  惊讶地发现， 如果在原来程序基础上只修改msg.h,  然后再make all的时候， 居然没有任何编译动作。

      于是继续在msg.h中写点其他东西， 然后make all, 发现也没有任何编译动作。看来，这里的makefile写的不够好。

      于是， 继续将程序只改两处：1. 在头文件msg.h中额msg结果提中只增加一个data字段； 2. 在a.cpp中值增加对应的pmsg->data = data;  然后编译， 分析了一下make all的执行过程， 发现只有a.cpp编译成了a.o,  test.cpp编译成了最终需要的test.so.  其余的并没有被编译  Oh, god, 终于知道原因了。

      原因： makefile写的不够好，修改msg.h和a.cpp后， a.cpp和test.cpp都重新编译了， 但包含了msg.h的b.cpp并没有重新编译， 也就是b.o中的结构体没有data这个字段， 于是， 当运行时， msg在库中传递的时候， 就出现了内存错误， 程序就崩溃了。 这里实际上就是协议文件(头文件msg.h)不一致导致的, 这与我们之前说过的客户端、服务端协议文件不一致导致core dump的问题如出一辙， 本质就是同一类问题。

      解决方法：

      1. 人为让b.cpp重新编译， 比如先执行make clean, 然后再make all  经验证， 能解决问题。

      2.  优化makefile, 当头文件msg.h变化时候， 所有直接或间接包含了它的cpp文件都重新编译。

 

      搞了好久， 才找到最根本的原因， 真是印象深刻

      成长， 需要踩坑。 以后我们自己写makefile也得要小心啊。