GDB实践：一场std::sort引发的coredump
以前只掌握gdb一些基础知识，还没有真正"实战"过。刚好最近同事一个进程coredump了，原因比较深，正好利用这个机会来分析下
// @ 运行：gdb [可执行程序] -c [coredump文件]
gdb edu_info_recommend_svr -c core_edu_info_recomm
// @ 查看堆栈信息：bt (backtrace)
(gdb) bt 10
#0 0x00007fa0809b6144 in __strcmp_sse42 () from /lib64/libc.so.6
#1 0x00000000004aa8f7 in Json::Value::CZString::operator< (this=, other=)
at /data/home/yaaf_proj/workspace/yaaf-ng/deps/libjsoncpp/json_value.cpp:191
#2 0x00000000004abf1a in operator() (this=, key=)
at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_function.h:230
#3 find (this=, key=) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:1424
#4 find (this=, key=) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_map.h:659
#5 Json::Value::operator[] (this=, key=) at /data/home/yaaf_proj/workspace/yaaf-ng/deps/libjsoncpp/json_value.cpp:1195
#6 0x0000000000438448 in Cmp6 (CourseInfo1=..., CourseInfo2=...) at /data/home/tinshuang/work/edu_proj/edu_info_recommend_svr/worker.cpp:226
#7 0x0000000000448a73 in __unguarded_partition<__gnu_cxx::__normal_iterator > >, Json::Value, bool (*)(Json::Value const&, Json::Value const&)> (__first=..., __last=..., __depth_limit=10, __comp=0x438430 )
at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_algo.h:2230
#8 std::__introsort_loop<__gnu_cxx::__normal_iterator > >, long, bool (*)(Json::Value const&, Json::Value const&)> (__first=..., __last=..., __depth_limit=10, __comp=0x438430 )
at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_algo.h:2301
#9 0x0000000000448aea in std::__introsort_loop<__gnu_cxx::__normal_iterator > >, long, bool (*)(Json::Value const&, Json::Value const&)> (__first=..., __last=..., __depth_limit=10, __comp=0x438430 )
at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_algo.h:2302
(More stack frames follow...) 从总的堆栈信息看，很多和STL与Json.Cpp相关，最终core在了Json.Cpp调用strcmp()上面。STL和Json.Cpp都是久经考验的第三方库，怎么可能会core？所以开始时很疑惑
// @ 切换当前栈：f (frame)
(gdb) f 1
#1 0x00000000004aa8f7 in Json::Value::CZString::operator< (this=, other=)
at /data/home/yaaf_proj/workspace/yaaf-ng/deps/libjsoncpp/json_value.cpp:191
191 return strcmp( cstr_, other.cstr_ ) < 0;
// @ 打印相关的源代码：l (list)
(gdb) l
187 bool
188 Value::CZString::operator<( const CZString &other ) const
189 {
190 if ( cstr_ )
191 return strcmp( cstr_, other.cstr_ ) < 0;
192 return index_ < other.index_;
193 }
// @ 查看当前栈|函数的入参：info args
(gdb) info args
this =
other = 可以看到，堆栈#1core在了json_value.cpp内的strcmp(cstr_, other.cstr_)里，但是打印参数this和other都是
(gdb) f 2
#2 0x00000000004abf1a in operator() (this=, key=)
at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_function.h:230
230 { return __x < __y; }
(gdb) l
225 template
226 struct less : public binary_function<_Tp, _Tp, bool>
227 {
228 bool
229 operator()(const _Tp& __x, const _Tp& __y) const
230 { return __x < __y; }
231 };
(gdb) info args
this = 0x3277aa0
__x = @0x7f9fbfeb2250
__y = @0x31c26b0
// @ 打印变量：p (print)
(gdb) p __x
$1 = (const Json::Value::CZString &) @0x7f9fbfeb2250: {
cstr_ = 0x50477b "sub_bgtime",
index_ = 0
}
(gdb) p __y
$2 = (const Json::Value::CZString &) @0x31c26b0: {
cstr_ = 0x0,
index_ = 0
} 可以看出，这一层堆栈core在了STL比较2个Json::Value::CZString类型变量的大小上。翻了Json.cpp的源代码，其实Json::Value::CZString只有2个变量：
{ const char * cstr_ ; int index_ }
其中cstr_表示CZString的具体字符串内容，但是可以发现，__y的cstr_=0x0，即指向NULL！(不是指向空串，空串是类似cstr_=0x50477b ""的形式)
再结合#0~#5和Json.Cpp的源代码，core的原因就比较清楚了：Json.Cpp调用[]在找"sub_bgtime"这个Key，其内部是用到std::map::find()来查找，std::map内部维护了一棵红黑树，红黑树在拿"sub_bgtime"和原有的Key(可简单看成const char*类型)做比较时，有一个Key=NULL，所以在调用strcmp("sub_bgtime",NULL)时，strcmp内部访问NULL引发了Segmentation fault段错误
所以现在问题就是为什么这个Json会有一个Key=NULL呢？从代码上看，是core在了对vector
(gdb) f 13
#13 0x0000000000442132 in InfoWorker::GetWillCourseListOnClient (this=0x15fb1e0, req_body=)
at /data/home/tinshuang/work/edu_proj/edu_info_recommend_svr/worker.cpp:894
// @ 设置打印选项：set print [pretty|union|static-members...] [on|off] (这里为了显示方便)
(gdb) set print union on
(gdb) set print static-members off
// @ 打印STL::vector：pvec (原生gdb对打印STL容器支持不是很好，网上这个叫dbinit_stl_views的小插件蛮好用的)
// 可以看到这个vector拥有193个元素(Json)，第1个Json值存储的内存地址为value_.map_，即0x13fe450
(gdb) pvec vec_course_list 0
elem[0]: $416 = {
value_ = {
int_ = 20964432,
uint_ = 20964432,
real_ = 1.0357805635774896e-316,
bool_ = 80,
string_ = 0x13fe450 "\020w\r\002",
map_ = 0x13fe450
},
type_ = Json::objectValue,
allocated_ = -1,
comments_ = 0x0
}
Vector size = 193
Vector capacity = 256
Element type = Json::Value *
// 按照其数据类型，把这个Json::Value内容打印出来。这里就可以看到这个Json::Value的各个Key了
(gdb) p *(Json::Value::ValueHolder::ObjectValues *) 0x13fe450
$419 = std::map with 18 elements = {
[{
cstr_ = 0x19598f0 "apply_num",
index_ = 1
}] = {
value_ = {
int_ = 1401,
uint_ = 1401,
real_ = 6.9218596982358641e-321,
bool_ = 121,
string_ = 0x579 ,
map_ = 0x579
},
type_ = Json::uintValue,
allocated_ = -1,
comments_ = 0x0
},
.... 到这里，就开始怀疑是std::sort有问题了，或者是我们使用不当。看了STL这块的源代码，比较晦涩，所以Google了下"stl sort core"，发现这个问题在网上已经被很多人提及到：std::sort()在排序时，如果比较函数对相等的元素返回true，会导致程序coredump
原因分析：std::sort()的排序分2种，当元素个数>16(_S_threshold)时选择快速排序，<=16个则选择插入排序(对象少时快排性能不理想)。按照快排原理，每次都是遍历所有值和一个中间值比较，小的放左边，大的放右边。从下面STL源代码可看出，std::sort()在遍历比较时，是没有边界保护的。如果比较相等的元素返回真，则在极端情况下(如所有元素相等，__pivot为最小|最大值时)会出现访问越界，导致coredump：
/// This is a helper function...
template
_RandomAccessIterator
__unguarded_partition(_RandomAccessIterator __first,
_RandomAccessIterator __last,
_Tp __pivot, _Compare __comp)
{
while (true)
{
while (__comp(*__first, __pivot))
++__first;
--__last;
while (__comp(__pivot, *__last))
--__last;
if (!(__first < __last))
return __first;
std::iter_swap(__first, __last);
++__first;
}
}