幫助解釋此堆棧跟蹤

Question

我知道它在strcmp失敗了。 我提供了operator <below，它調用了strcmp。

在＃1行，有值@ 0xbfffeeac。 @是什么意思？

#0  0x00212bd8 in strcmp () from /lib/libc.so.6
#1  0x0012ed2f in Json::Value::CZString::operator< (this=0x8317300, other=@0xbfffeeac)
    at src/lib_json/json_value.cpp:221
#2  0x001361b0 in std::less<Json::Value::CZString>::operator() (this=0x83173a0, __x=@0x8317300, 
    __y=@0xbfffeeac)
    at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_function.h:230
#3  0x00136101 in std::_Rb_tree<Json::Value::CZString, std::pair<Json::Value::CZString const, Json::Value>, std::_Select1st<std::pair<Json::Value::CZString const, Json::Value> >, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::_M_lower_bound (this=0x83173a0, 
    __x=0x83172f0, __y=0x83173a4, __k=@0xbfffeeac)
    at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_tree.h:986
#4  0x001348da in std::_Rb_tree<Json::Value::CZString, std::pair<Json::Value::CZString const, Json::Value>, std::_Select1st<std::pair<Json::Value::CZString const, Json::Value> >, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::find (this=0x83173a0, __k=@0xbfffeeac)
    at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_tree.h:1421
#5  0x0013383a in std::map<Json::Value::CZString, Json::Value, std::less<Json::Value::CZString>, std::allocator<std::pair<Json::Value::CZString const, Json::Value> > >::find (this=0x83173a0, __x=@0xbfffeeac)
    at /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_map.h:659
#6  0x00131779 in Json::Value::operator[] (this=0x8317280, key=0xbfffef74 "col1")
    at src/lib_json/json_value.cpp:1055
#7  0x00131ba8 in Json::Value::isMember (this=0x8317280, key=0xbfffef74 "col1")
    at src/lib_json/json_value.cpp:1169
#8  0x0805cf4d in CFG::CFG_Fetch_Raw (this=0x825846c, section=0x8317280, key=0xbfffef74 "col1", defval=0x0)
    at CFG.cpp:48
#9  0x08050e5b in Generic::CFGSetup (this=0x825846c, k=0x8255e2c "display_qt") at Generic.cpp:89
#10 0x0804df6a in LCDControl::ConfigSetup (this=0xbffff2a8) at LCDControl.cpp:81
#11 0x0804d93b in LCDControl::Start (this=0xbffff2a8, argc=1, argv=0xbffff404) at LCDControl.cpp:15
#12 0x0804f224 in main (argc=1, argv=0xbffff404) at Main.cpp:7

bool
Value::CZString::operator<( const CZString &other ) const
{
   if ( cstr_ )
      return strcmp( cstr_, other.cstr_ ) < 0; //src/lib_json/json_value.cpp:221
   return index_ < other.index_;
}

Answer 1

你正在檢查this->cstr_為null，但是你沒有檢查other.cstr_ 。 也許容器會阻止插入具有null cstr_值的任何字符串，因此不需要進行此類檢查。

然而，這不是問題，因為在這種情況下其他不是null。 而是看起來other對象可能已被刪除。 你如何管理std::map容器中對象的生命周期？ 是否有可能刪除其中一個值而未從地圖中刪除？

更新：

在進一步檢查時，這似乎是關鍵：

#5  0x0013383a in std::map<...>::find (this=0x83173a0, __x=@0xbfffeeac)
#6  0x00131779 in Json::Value::operator[] (this=0x8317280, key=0xbfffef74 "col1")

你傳入一個常量字符串指針（0xbfffef74，顯然有效，因為調試器顯示字符串），並且它會自動轉換為CZString類型的臨時值。 您可以看到臨時CZString對象忠實地傳遞給operator< 。

我相信0x8...地址表示堆分配，而0xbf...地址表示堆棧分配。

不幸的是，我們需要看到的是strcmp()的參數。 我們需要知道，當CZString::operator<被調用0xbfffeeac （臨時CZString對象）的“其他”參數時，是否將原始字符串值0xbfffef74給strcmp ，或者是否為堆分配的副本string（我不知道CZString在內部做什么）。

如果這是b樹搜索中的第一個比較，那可能表明strcmp的第二個參數未正確轉換為CZString 。 否則，它表示第二個參數正確傳遞，並且地圖中的一個字符串無效但不為空，留下“已刪除”和“非空終止”可能是可疑的。

Answer 2

@ 0xbfffeeac看起來像一個特殊的值，也許是未初始化的內存？ 我只是猜測，但是@符號可以放在那里表示內存地址指向一個特殊格式的值來表示未初始化的內存嗎？

Answer 3

@符號表示參數是通過引用傳遞的。

為了幫助理解程序的內存映射，例如數據段中的地址與堆棧中的地址，請嘗試gdb下的info files 。 此外，由於您在Linux下運行，請查看cat /proc/<pid>/maps 。

Answer 4

也許strcmp在運行時接收到意外的值，或者某種東西。 只是一個想法，抱歉，如果我錯了。