删除以结构为键的地图时出现分段错误

Posted 2023-02-16

【中文标题】删除以结构为键的地图时出现分段错误

【英文标题】：segmentation fault when deleting a map with struct being the keys

【发布时间】：2012-02-29 15:51:10

【问题描述】：

在我的代码中，我有一个用作映射键的结构：

struct index
  int x;
  int y;
  int z;
  bool operator<(const index &b)
    bool out = true;
    if ( x == b.x )
      if ( y == b.y )
        out = z < b.z;
       else out = y < b.y;
     else out = x < b.x;
    return out;
  
;

我使用的地图是：

map<index,set<std::pair<int, int> > > tBoxes;

当程序运行结束时，它尝试释放内存，当程序尝试删除映射时出现分段错误。使用 gdb 我得到：

#0  std::_Rb_tree<membrane::index, std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > >, std::_Select1st<std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > > >, std::less<membrane::index>, std::allocator<std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > > > >::_M_erase (this=0x63b900, 
    __x=0x404057eb274ede6c)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:1264
#1  0x000000000041ed2f in std::_Rb_tree<membrane::index, std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > >, std::_Select1st<std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > > >, std::less<membrane::index>, std::allocator<std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > > > >::_M_erase (
    this=0x63b900, __x=0x7d31110)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:1264
#2  0x000000000041ed2f in std::_Rb_tree<membrane::index, std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > >, std::_Select1st<std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > > >, std::less<membrane::index>, std::allocator<std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > > > >::_M_erase (
    this=0x63b900, __x=0x7d30e30)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:1264
#3  0x000000000041ed2f in std::_Rb_tree<membrane::index, std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > >, std::_Select1st<std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > > >, std::less<membrane::index>, std::allocator<std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > > > >::_M_erase (
    this=0x63b900, __x=0x7d30b50)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:1264
#4  0x000000000041ed2f in std::_Rb_tree<membrane::index, std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > >, std::_Select1st<std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > > >, std::less<membrane::index>, std::allocator<std::pair<membrane::index const, std::set<std::pair<int, int>, std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > > > > >::_M_erase (
    this=0x63b900, __x=0x7d272c0)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:1264
#5  0x0000000000418237 in clear (this=0x63b3e0, 
    __in_chrg=<value optimized out>)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:692
#6  clear (this=0x63b3e0, __in_chrg=<value optimized out>)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_map.h:501
#7  membrane::~membrane (this=0x63b3e0, __in_chrg=<value optimized out>)
    at memMC.cpp:135
#8  0x0000000000421658 in __tcf_5 () at main.cpp:7
#9  0x000000378ea334f5 in exit () from /lib64/libc.so.6
#10 0x000000378ea1d99b in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000402309 in _start ()

使用 valgrind（运行 $valgrind -v --track-origins=yes --leak-check=yes --tool=massig --tool=memcheck --read-var-info=yes --log-file=error.txt ./mem）我得到：

==2561==     in use at exit: 0 bytes in 0 blocks
==2561==   total heap usage: 3,346,323 allocs, 3,346,323 frees, 98,851,279 bytes allocated
==2561== 
==2561== All heap blocks were freed -- no leaks are possible
==2561== 
==2561== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
--2561-- 
--2561-- used_suppression:      4 dl-hack3
==2561== 
==2561== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

这很烦人，因为它什么也没告诉我。

我试图手动清除地图（同时打印一些可能会提供一些线索的输出：

while (tBoxes.size() > 0)
   printf ("%i  ", (*tBoxes.begin()).first.x);
   printf ("%i  ", (*tBoxes.begin()).first.y);
   printf ("%i\n", (*tBoxes.begin()).first.z);
   while ((*tBoxes.begin()).second.size() > 0)
     printf ("a\n");      
     tgBit1 = (*tBoxes.begin()).second.begin();
     (*tBoxes.begin()).second.erase(tgBit1);
     printf ("b\n");
   
   tBoxes.erase(tBoxes.begin());
 
 tBoxes.clear();
 tNextBoxes.clear();

我所能收集到的只是当我将 x 从 0 增加到 1 并且它发生在我删除集合的内容之后 时删除崩溃。

为什么会发生这种情况？除了使用 clear() 之外，还有其他方法可以清除地图吗？

编辑：

我发现了错误。我使用的向量之一设置不正确，实际上大小为 0。但是，我仍然访问了该向量中的元素。

向量是double 值，我在除以框大小并将结果向下舍入以确定要放入一对的tBox 后使用该值。我假设我得到了一个无效值来使用index。问题仍然存在，为什么当我尝试访问该元素时程序没有崩溃...？

【问题讨论】：

你能发布一个小的可编译程序来重现这个吗？

不清楚你的意思是在哪里将 x 从 0 增加到 1。这是在你的一个键中吗？在这种情况下，这是不允许的，密钥必须保持不变。这会打乱排序。

【参考方案1】：

我的猜测是在您的程序中的其他地方发生了某种堆/堆栈损坏，只有当您的映射尝试访问错误的指针/迭代器时才会表现出来。查看最后一个被擦除的迭代器 (0x404057eb274ede6c)，与之前的迭代器值 (0x7d31110) 相比，它看起来很可疑。

为什么 Valgrind 没有检测到这种损坏？我对该工具不是很熟悉，但 SE 上的 this question 指出了 Valgrind 未能检测到“明显”不良行为的另一种情况，并且还建议了其他方法来帮助检测它。

我会尝试将崩溃减少到尽可能少的代码。在另一个项目中创建一个小测试用例，看看是否仍然发生崩溃。在调试模式下运行和/或使用额外的内存检查来查看是否可以捕获内存损坏（假设是这样）。

编辑更新：

假设您使用的是std::vector::operator[]，那么此方法不会进行任何边界检查，并且很乐意让您尝试访问不存在的元素。我相信这被指定为未定义的行为，不幸的是，一个可能的结果是什么都没有发生。

如果您希望或需要使用std::vector::at() 对它们进行边界检查，请参阅this question 了解一些详细信息。通常，只有在知道所使用的索引在界限内时才使用[]，例如在迭代循环中或手动检查索引时。

【讨论】：

非常感谢您的回答。最终错误出现在其他地方（我会更新我的问题）。但是你玩弄我一些方便的工具。