我正在努力追踪一个错误，这个错误偶尔会在这个琐碎的C++类的析构函数中使我的应用程序崩溃：
class CrashClass {
public:
CrashClass(double r1, double s1, double r2, double s2, double r3, double s3, string dateTime) : mR1(r1), mS1(s1), mR2(r2), mS2(s2), mR3(r3), mS3(s3), mDateTime(dateTime) { }
CrashClass() : mR1(0), mS1(0), mR2(0), mS2(0), mR3(0), mS3(0) { }
~CrashClass() {}
string GetDateTime() { return mDateTime; }
private:
double mR1, mS1, mR2, mS2, mR3, mS3;
string mDateTime;
};
这些对象中的一堆被固定在标准C++vector中，并在第二个类中使用：
class MyClass {
(...)
private:
vector<CrashClass> mCrashClassVec;
};
MyClass根据需要多次被创建和解除锁定。
该代码在macOS 10.14.4下的最新Xcode 10.1上使用C++17。
所有这些都是计算密集型模拟应用程序的一部分，该应用程序运行数小时至数天。在一台6核i7机器上，并行运行12次计算(使用macOS的GCD框架)，使用几个小时后，它经常崩溃
未分配释放的指针
对MyClass中的成员调用mCrashClassVec.clear()时出错，即
frame #0: 0x00007fff769a72f6 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00000001004aa80d libsystem_pthread.dylib`pthread_kill + 284
frame #2: 0x00007fff769116a6 libsystem_c.dylib`abort + 127
frame #3: 0x00007fff76a1f977 libsystem_malloc.dylib`malloc_vreport + 545
frame #4: 0x00007fff76a1f738 libsystem_malloc.dylib`malloc_report + 151
frame #5: 0x0000000100069448 BackTester`MyClass::DoStuff(int, int) [inlined] std::__1::__libcpp_deallocate(__ptr=<unavailable>) at new:236 [opt]
frame #6: 0x0000000100069443 BackTester`MyClass::DoStuff(int, int) [inlined] std::__1::allocator<char>::deallocate(__p=<unavailable>) at memory:1796 [opt]
frame #7: 0x0000000100069443 BackTester`MyClass::DoStuff(int, int) [inlined] std::__1::allocator_traits<std::__1::allocator<char> >::deallocate(__p=<unavailable>) at memory:1555 [opt]
frame #8: 0x0000000100069443 BackTester`MyClass::DoStuff(int, int) [inlined] std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_string() at string:1941 [opt]
frame #9: 0x0000000100069439 BackTester`MyClass::DoStuff(int, int) [inlined] std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_string() at string:1936 [opt]
frame #10: 0x0000000100069439 BackTester`MyClass::DoStuff(int, int) [inlined] CrashClass::~CrashClass(this=<unavailable>) at CrashClass.h:61 [opt]
frame #11: 0x0000000100069439 BackTester`MyClass::DoStuff(int, int) [inlined] CrashClass::~CrashClass(this=<unavailable>) at CrashClass.h:61 [opt]
frame #12: 0x0000000100069439 BackTester`MyClass::DoStuff(int, int) [inlined] std::__1::allocator<CrashClass>::destroy(this=<unavailable>, __p=<unavailable>) at memory:1860 [opt]
frame #13: 0x0000000100069439 BackTester`MyClass::DoStuff(int, int) [inlined] void std::__1::allocator_traits<std::__1::allocator<CrashClass> >::__destroy<CrashClass>(__a=<unavailable>, __p=<unavailable>) at memory:1727 [opt]
frame #14: 0x0000000100069439 BackTester`MyClass::DoStuff(int, int) [inlined] void std::__1::allocator_traits<std::__1::allocator<CrashClass> >::destroy<CrashClass>(__a=<unavailable>, __p=<unavailable>) at memory:1595 [opt]
frame #15: 0x0000000100069439 BackTester`MyClass::DoStuff(int, int) [inlined] std::__1::__vector_base<CrashClass, std::__1::allocator<CrashClass> >::__destruct_at_end(this=<unavailable>, __new_last=0x00000001011ad000) at vector:413 [opt]
frame #16: 0x0000000100069429 BackTester`MyClass::DoStuff(int, int) [inlined] std::__1::__vector_base<CrashClass, std::__1::allocator<CrashClass> >::clear(this=<unavailable>) at vector:356 [opt]
frame #17: 0x0000000100069422 BackTester`MyClass::DoStuff(int, int) [inlined] std::__1::vector<CrashClass, std::__1::allocator<CrashClass> >::clear(this=<unavailable>) at vector:749 [opt]
旁注：正在清除的vector可能还没有元素。
在堆栈跟踪(bt all)中，我可以看到其他线程对其CrashClass向量的副本执行操作，但就我所见，从堆栈跟踪中的地址比较来看，所有这些实际上都是私有副本(如设计的那样)，即线程之间没有共享这些数据。
自然错误只发生在完全生产模式下，即所有复制崩溃的尝试
- 在DEBUG模式下运行
- 在Lldb(Xcode)地址消毒器下运行(对于许多小时/过夜)
- 在Lldb(Xcode)线程消毒器下运行(对于许多小时/过夜)
- 运行类的精简版本，只保留/复制关键代码
失败并且没有触发崩溃。
为什么释放堆栈上分配的简单成员失败，释放的指针未分配错误？
此外，关于如何调试或在更健壮的环境中触发错误以进行进一步调查的其他提示也非常受欢迎。
更新5/2019
这个错误仍然会间歇性地导致应用程序崩溃，我开始相信我遇到的问题实际上是由英特尔最近CPU型号中的数据损坏错误引起的。。
https://mjtsai.com/blog/2019/05/17/microarchitectural-data-sampling-mds-mitigation/
https://mjtsai.com/blog/2017/06/27/bug-in-skylake-and-kaby-lake-hyper-threading/
https://www.tomshardware.com/news/hyperthreading-kaby-lake-skylake-skylake-x，34876.html
您可以尝试一些技巧：
- 使用单个线程运行生产版本更长的时间(比如一周或两周)，看看它是否崩溃
- 考虑到可能存在内存碎片，请确保您没有消耗所有可用的RAM
- 确保程序运行时间越长，内存不会泄漏或增加内存使用率
- 通过添加额外的值来添加一些跟踪，将值设置为析构函数中已知的值(这样，如果进行双重删除，您就可以识别模式)
- 请尝试在另一个平台和编译器下运行该程序
- 您的编译器或库可能包含错误。请尝试其他(更新的)版本
- 从原始版本中删除代码，直到它不再崩溃。如果你能用一个以某种方式破坏内存的序列来持续地获得崩溃，那么效果会更好
- 一旦发生崩溃，请使用完全相同的数据(对于每个线程)运行程序，看看它是否总是在同一位置崩溃
- 重写或验证应用程序中的任何不安全代码。避免强制转换、printf和其他老派变量参数函数以及任何不安全的strcpy和类似函数
- 使用已检查的STL版本
- 尝试未优化的发布版本
- 尝试优化的调试版本
- 了解编译器的DEBUG和RELEASE版本之间的区别
- 从零重写有问题的代码。也许它不会有bug
- 在数据崩溃时检查数据
- 检查错误/异常处理，看看是否忽略了一些潜在的问题
- 测试程序在内存不足、磁盘空间不足以及引发异常时的行为
- 请确保调试器在每个已处理或未处理的抛出异常时停止
- 请确保您的程序在编译和运行时没有警告，或者您理解这些警告，并确保它无关紧要
- 当数据崩溃时，请检查数据是否正常
- 您可以保留内存以减少碎片和重新分配。如果你的程序运行了几个小时，可能是内存碎片太多，系统找不到足够大的块
- 由于您的程序是多线程的，请确保您的运行时也与之兼容
- 确保不跨线程共享数据，或者确保它们得到充分的保护