帮助解释这个堆栈跟踪

Question

我知道它在 strcmp 处失败。我已经提供了运算符<下面，它调用 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_。也许容器会阻止插入任何具有空 cstr_ 值的字符串，因此不需要进行这样的检查。

然而，这不是问题，因为在这种情况下 other 不为空。相反，看起来 other 对象可能已被删除。您如何管理 std::map 容器中对象的生命周期？是否有可能删除其中一个值而没有从地图中删除？

更新：

经过进一步检查，这似乎是关键：

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

您传递一个常量字符串指针（0xbffffef74，这显然是有效的，因为调试器显示该字符串），并且它会自动转换为 CZString。您可以看到临时 CZString 对象一直忠实地传递给 operator<。

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

不幸的是，我们需要看到的是 strcmp() 的参数。我们需要知道，当使用 0xbfffeeac（临时 CZString 对象）的“其他”参数调用 CZString::operator< 时，是否将 0xbffffef74 的原始字符串值传递到 strcmp 中，或者可能是该字符串的堆分配副本（我不知道 CZString 内部做了什么）。

如果这是 b 树搜索中的第一次比较，则可能表明 strcmp 的第二个参数未正确转换为 CZString。否则，它表明第二个参数正在正确传递，并且映射中的字符串之一无效但不为空，因此可能怀疑“已删除”和“非空终止”。

Answer 2

@0xbfffeeac 看起来像一个特殊的值，也许是未初始化的内存？我只是猜测，但是可以将 @ 符号放在那里来指示内存地址指向特殊格式的值以指示未初始化的内存吗？

Answer 3

@ 符号表示参数是通过引用传递的。

为了帮助理解程序的内存映射，例如数据段中的地址与堆栈中的地址，请尝试 gdb 下的 info files。另外，由于您在 Linux 下运行，请检查 cat /proc//maps 的输出。

Answer 4

也许 strcmp 在运行时接收到意外的值，或者其他什么。只是一个想法，如果我错了，抱歉。