这个问题是我在开发心跳服务器时的一个笔误，其实错误非常的低级浅显，特别写篇文章是想告诉大家，编译期的警告是非常重要的！由于项目代码量大，编译期信息很多，我在忙于联调时就悲催的忽视了一条编译期警告信息，实际上这个警告解决问题实在是方便，我忽略了它直接从core上啃哧啃哧定位问题花的时间比之多了去了。这篇文章的目的就是以这个很天真又很容易犯的笔误错误，来提醒大家：请不要忽略任何编译期的警告，磨刀不误砍柴工，它会极大的节省定位BUG的时间！同时，这篇文章在定位Illegal instruction错误时，也说明了gdb的bt显示的core代码行为什么是错误的。
心跳服务器是一个多线程服务器，提供UDP和HTTP服务，日志记录使用了log4cpp。由于各种原因项目不断延迟，所以这个服务器的代码我好一段时间没碰了。这会儿改了一大堆代码，功能测试都通过了，开始做压力测试。压力客户端模拟数以百计的客户端时一直没出问题，直到千、万级时，开始不定时的出现coredump核心转储。问题可以重现，但必须是大压力下，不好单步调。于是只能先产生core文件并分析之：
很诡异，居然会core在了break这行代码上，有点浮想联翩，break怎么可能会挂掉呢？有蹊跷。这段代码结构是这样的：
分析这个break曾经行经的代码分支，实在找不到原因。
再看看到底挂在了哪行汇编语句下：
有点恍然了， ud2a一般都是编译时出了问题！
于是再对照着compete函数看看编译后的汇编代码：
现在明白了，原来bt后显示的C代码挂在的break语句是错误的（可能是编译优化所致）！汇编代码显示是挂在了INFO()这行打印日志的语句上，当然以汇编为准了！于是看 if (procNum >=m_iCompeteMaxNumOneTime)?条件为假时，其实是去执行INFO_LOG("id[%s] ...",?packet->strid, ...);，但为什么编译器显示为ud2a呢？
阅读代码时发现，INFO_LOG("id[%s]中的第1个参数，被临时改为了packet->strid，而这个strid并不是char*，而是c++中stl里的string对象！一个非常浅显的错误。
实际上，这种笔误问题编译器早就发现了，
SAT培训只是我对打印了几个屏的make结果忽视了，发现编译完成后就开始测试了。编译时的警告信息很清晰：
可见，gcc提示的非常清楚，使用错string对象了！
写了这么多，我想说的是，在每一次编译过程中，都要非常认真的对待编译期的警告信息，这会大大节省定位问题的时间，否则就不得不苦逼的一行行去查到底哪里出问题了。