Warning: file_get_contents(/data/phpspider/zhask/data//catemap/6/cplusplus/144.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
C++ _DebugHeapDelete在终止时访问冲突_C++_Access Violation_Termination - Fatal编程技术网

C++ _DebugHeapDelete在终止时访问冲突

C++ _DebugHeapDelete在终止时访问冲突,c++,access-violation,termination,C++,Access Violation,Termination,在我的主要任务结束时,我遇到了一个奇怪的访问违规问题,我很难找到它的原因 关闭应用程序时,我会遇到以下访问冲突: xdebug // TEMPLATE FUNCTION _DebugHeapDelete template<class _Ty> void __CLRCALL_OR_CDECL _DebugHeapDelete(_Ty *_Ptr) { // delete from the debug CRT heap even if operator

在我的主要任务结束时,我遇到了一个奇怪的访问违规问题,我很难找到它的原因

关闭应用程序时,我会遇到以下访问冲突:

xdebug

        // TEMPLATE FUNCTION _DebugHeapDelete
template<class _Ty>
    void __CLRCALL_OR_CDECL _DebugHeapDelete(_Ty *_Ptr)
    {   // delete from the debug CRT heap even if operator delete exists
    if (_Ptr != 0)
        {   // worth deleting
        _Ptr->~_Ty();
        // delete as _NORMAL_BLOCK, not _CRT_BLOCK, since we might have
        // facets allocated by normal new.
        free(_Ptr); // **ACCESS VIOLATION**
        }
    }
//模板函数\u DebugHeapDelete
模板
void\u CLRCALL\u或\u CDECL\u DebugHeapDelete(\u Ty*\u Ptr)
{//从调试CRT堆中删除,即使存在运算符delete
如果(_Ptr!=0)
{//值得删除
_Ptr->~\u Ty();
//删除为正常块,而不是CRT块,因为我们可能有
//由普通新用户分配的面。
免费(_Ptr);//**访问冲突**
}
}
堆栈跟踪:

>   msvcp100d.dll!std::_DebugHeapDelete<void>(void * _Ptr)  Line 62 + 0xa bytes C++
    msvcp100d.dll!std::numpunct<char>::_Tidy()  Line 190 + 0xc bytes    C++
    msvcp100d.dll!std::numpunct<char>::~numpunct<char>()  Line 122  C++
    msvcp100d.dll!std::numpunct<char>::`scalar deleting destructor'()  + 0x11 bytes C++
    msvcp100d.dll!std::_DebugHeapDelete<std::locale::facet>(std::locale::facet * _Ptr)  Line 62 C++
    msvcp100d.dll!std::_Fac_node::~_Fac_node()  Line 23 + 0x11 bytes    C++
    msvcp100d.dll!std::_Fac_node::`scalar deleting destructor'()  + 0x11 bytes  C++
    msvcp100d.dll!std::_DebugHeapDelete<std::_Fac_node>(std::_Fac_node * _Ptr)  Line 62 C++
    msvcp100d.dll!_Fac_tidy()  Line 41 + 0x9 bytes  C++
    msvcp100d.dll!std::_Fac_tidy_reg_t::~_Fac_tidy_reg_t()  Line 48 + 0xe bytes C++
    msvcp100d.dll!std::`dynamic atexit destructor for '_Fac_tidy_reg''()  + 0xf bytes   C++
    msvcp100d.dll!_CRT_INIT(void * hDllHandle, unsigned long dwReason, void * lpreserved)  Line 415 C
    msvcp100d.dll!__DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved)  Line 526 + 0x11 bytes  C
    msvcp100d.dll!_DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved)  Line 476 + 0x11 bytes   C
>msvcp100d.dll!STD::OxDebug 62删除+0xA字节C++
msvcp100d.dll!STD::NoStutt::(190)+0xC字节C++
msvcp100d.dll!STD::NoNotht::~ NothCuthTo()122行C++
msvcp100d.dll!STD::NoMuxt::“标量删除析构函数”(++0x11字节C++)
msvcp100d.dll!STD::OdTraceHeAdEd删除(STD::LoaLe::FACET**PTR)62 C++
msvcp100d.dll!STD::~(23)+FACH NODEE():行+0x11字节C++
msvcp100d.dll!STD::* FACHNONT::“标量删除析构函数”(++0x11字节C++)
msvcp100d.dll!STD::OxDebug HealdLead(STD::* FasHealNoth**PPTR)62 C++
msvcp100d.dll_(41)+0x9字节C++
msvcp100d.dll!St:::FasHyTyDyReGyt::~~ FasuthTiyReGug()行48 +0xE字节C++
msvcp100d.dll!STD::'AfthFasTiyDyRe''()+0xf字节C++的动态ATSebug析构函数
msvcp100d.dll_CRT_INIT(void*hDllHandle,无符号长dwReason,void*lpreserved)行415 C
msvcp100d.dll__DllMainCRTStartup(void*hDllHandle,无符号长dwReason,void*lpreserved)行526+0x11字节C
msvcp100d.dll_DllMainCRTStartup(void*hDllHandle,无符号长dwReason,void*lpreserved)行476+0x11字节C
有人知道是什么导致了这一切吗


我读到一些关于缓存方面的文章,不确定这是否相关?

内存损坏错误(显然)会导致这种(以及其他许多类型的)故障

您是否尝试过使用valgrind(memcheck)或rationalpurify来解决这个问题?它可能会报告问题(如果这是您第一次对代码库运行这样的检查,则可能会隐藏在大量其他信息中)。您仍然希望设计一个最小的“主”实现,以展示在内存和边界检查器下运行的行为

$0.02

顺便一提,为了以防万一,通常会出现内存损坏错误

  • 通过取消对过时指针的引用(在释放/删除之后)
  • 通过在已分配缓冲区的结尾之外写入
  • 通过释放/删除以前的指针(主要是所有权跟踪不良的症状)

    • 如果您覆盖新的操作员并使用,您可能会遇到与我相同的原因。 代码可能类似于

      #include "yournew" //override new declare .. 
      #include "fstream" 
      std::fstream f
      f.open(...)
      

      因为iostream是模板,所以新的_Fac_节点使用运算符new。但是当退出时,内存池可能在_Fac_tidy之前退出,然后在~_Fac_tidy()时退出运行时,程序崩溃。

      我相信您的体验与我在MSVC10运行时的体验相同。据我所知,这是由于运行时在DLL卸载时删除全局方面,然后在进程结束时再次删除它造成的。如果您以静态方式链接所有内容,则不会发生这种情况。在MSVC9中,也不会发生静态链接或共享链接。

      第一个已接受的响应是正确的,但它没有确切显示原因,因此也没有显示修复方法。根据调用堆栈中列出的部分,我在VC++8(MS VS 2005)中遇到了相同的问题,但情况不同:我的CLR DLL在代码的同一点导致AV

      从列出的调用堆栈可以看出,调用了通常编译成msvc*.dll的
      代码,但此时
      \u Ptr
      已经有错误的值。因此,有些代码已经释放了该指针下的对象,或者设置了一个退出挂钩来释放未初始化的对象

      如果定义了,则可以将
      代码编译到加载到应用程序进程中的其他模块中。然后,这些模块的一个退出过程可以在msvcp100d.dll中的另一个退出过程之前调用,因此通常可以释放facet对象。在我的例子中,定义了
      \u STATIC\u CPPLIB
      后,两个模块(exe和clr dll)已编译

      VC++8,9的解决方案 检查“命令行”部分中的最终编译器选项是否存在
      /D“\u STATIC\u CPPLIB”
      。取消定义
      \u STATIC\u CPPLIB
      并重新编译受影响的模块可在程序终止时修复AV

      关于
      \u STATIC\u CPPLIB
      因为,在MSDN,有一条注释是

      \u STATIC\u CPPLIB
      预处理器定义和
      /clr
      /clr:pure
      编译器选项不受支持

      对于更高版本的VS,没有提到
      \u STATIC\u CPPLIB

      对于更高的VS版本,特别是VS 10,我假设依赖于
      \u STATIC\u CPPLIB
      的代码仍然存在。在TS的情况下,如果任何TU的编译器选项中仍然使用
      \u STATIC\u CPPLIB
      ,包括
      的其他头文件,这种不正确的组合可能导致AV。

      您所做工作的最小示例代码。@Mahesh:我很乐意,但我有10000多行代码。由于问题发生在main的末尾(我在main的return语句中设置了一个断点,在这一点上还没有出现问题)我不知道哪些行可能与问题相关。我想我的问题是,是否有人知道什么样的错误可能导致此故障?