STL对象出现运行时错误Core的几个可能原因

写C++服务器程序时发现几次Core在了STL对象操作中，这种问题非常难以定位，因为基本上不用去怀疑STL的正确性。而且这种问题往往很少复现，所以分析起来就更头疼了。下面分享下几次定位出的问题点，以供分享，同时也作为自己的一个记录。

 

1. gcc版本不一致，编译环境的GCC版本和运行环境的GCC版本不一致。

---这种情况出现core后，从上下文分析完全没有逻辑，所以自己部署程序时必须保证编译环境和运行环境GCC完全一致，包括程序用到的其它动态库，如libssl, libmysqlclient 等等都尽量保证一致，这样才能避免莫名其妙问题的产生。

 

2. 修改代码后没有Make clean；直接Make

---这种做法在少数情况下同样会产生莫名奇妙的问题，所以建议大家不要省那么写重新make的时间以避免问题。

 

3.stl对象内存被踩

---这种情况常出现在stl对象作为静态或全局变量时，解决这种问题的方法和分析通常问题一样，可以分为3步：

   A. review代码,分析上下文，分析内存位置和出错对象相近的地方。(可通过工具查看静态空间分配，堆上的动态则可以通过打印地址来查看)

   B. 增加log，在整个运行栈都增加对出错stl对象的打印以及模拟操作。(适用于不可复现的情况)

   C. 屏蔽代码，定位出错位置。即逐步的减少代码。(仅适用于可复现的问题)

 

4.*.h文件包含顺序(这个问题相当诡异，没有找到任何文章说明这种问题的原因)

---通常*.h包含顺序为系统库，外部库，内部*.h，并且*.h的包含问题一般都能在编译，链接时检测出来，但我就遇到了这种编译链接都没问题，运行时却偶尔core，调整*.h顺序后OK的情况。 对于这种问题没有什么好的方法，只能提出下面几个原则性的建议。

   A. 尽量在*.cpp里面包含*.h，而不要在*.h包含。

   B. 避免循环包含，如a.h include b.h, b.h include a.h, 可以重构为 a.h inlcude c.h, b.h include c.h

   C.在以上方法都没有解决问题时则可以尝试将内部代码的*.h包换在所有*.h之前。(这招没有什么规律，需要多次尝试，但本人的问题就是这样解决的...)

 

-------希望以上的方法对大家有帮助，提供下思路，不至于碰到stl对象core就头大了。