_DebugHeapDelete终止访问冲突 [英] _DebugHeapDelete Access Violation at termination

问题描述

在主程序结尾处出现奇怪的访问冲突，其原因是我在查找问题时遇到了一些困难。

关闭应用程序时，我会收到一个以下访问冲突：

xdebug

  //模板功能_DebugHeapDelete 
 template< class _Ty> 
 void __CLRCALL_OR_CDECL _DebugHeapDelete（_Ty * _Ptr）
 {//即使存在删除操作符，也要从调试CRT堆中删除
 if（_Ptr！= 0）
 {//值得删除
 _Ptr->〜_Ty（）; 
 //删除为_NORMAL_BLOCK，而不是_CRT_BLOCK，因为我们可能会通过常规new分配
 //构面。 
 free（_Ptr）; // **访问违规** 
} 
} 
  

堆栈跟踪：

 > msvcp100d.dll！std :: _ DebugHeapDelete< void>（void * _Ptr）第62行+ 0xa字节C ++ 
 msvcp100d.dll！std :: numpunct< char> :: _ Tidy（）第190行+ 0xc字节C ++ 
 msvcp100d.dll！std :: numpunct< char> :::〜numpunct< char>（）第122行C ++ 
 msvcp100d.dll！std :: numpunct< char> ::`标量删除析构函数'（）+ 0x11字节C ++ 
 msvcp100d.dll！std :: _ DebugHeapDelete< std :: locale :: facet>（std :: locale :: facet * _Ptr）第62行C ++ 
 msvcp100d.dll！std :: __ Fac_node ::〜_Fac_node（）第23行+ 0x11字节C ++ 
 msvcp100d.dll！std :: _ Fac_node ::`标量删除析构函数'（）+ 0x11字节C ++ 
 msvcp100d.dll！std :: _ DebugHeapDelete< std :: _ Fac_node>（std :: __ Fac_node * _Ptr）第62行C ++ 
 msvcp100d.dll！_Fac_tidy（）第41行+ 0x9字节C ++ 
 msvcp100d.dll！std :: _ Fac_tidy_reg_t ::〜__Fac_tidy ）第48行+ 0xe字节C ++ 
 msvcp100d.dll！std ::`_Fac_tidy_reg的动态atexit析构函数（）+ 0xf字节C ++ 
 msvcp100d.dll！_CRT_INIT（void * hDllHandle，unsigned long dwReason，void * lpreserved）行415 C 
 msvcp100d.dll！__ DllMainCRTStartup（void * hDllHandle，unsigned long dwReason，void * lpreserved）行$ 526 + 0x11 b $ b msvcp100d.dll！_DllMainCRTStartup（void * hDllHandle，unsigned long dwReason，void * lpreserved）476行+ 0x11字节C 
  

任何人都知道可能是什么原因造成的？

我读过一些有关缓存方面的内容，不确定是否相关？

解决方案

内存损坏错误可能（显然）会导致这种（以及许多其他类型的）失败。

您是否尝试过使用valgrind（memcheck）或Rational Purify来解决此问题？它可能会报告该问题（如果这是您第一次在代码库上进行这样的检查，则可能会包含很多其他信息。您仍然想要设计一个最小的主要展示了在内存和边界检查器下运行的行为的实现。

$ 0.02

PS，以防万一，通常会通过取消引用过时的指针（在释放/删除后）

• by通过释放/删除先前的指针（主要是所有权跟踪错误的症状）来写超出已分配缓冲区的末尾

I'm getting a weird access violation at the end of my main whose cause I'm having some difficulties finding.

When shutting down my application I get an access violation in the following:

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**
        }
    }

Stack trace:

>   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

Anyone got any ideas as to what might cause this?

I read something about facets being cached not sure if thats related?

解决方案

Memory corruption bugs can (obviously) cause this (and many other kinds) of failure.

Have you tried using valgrind (memcheck) or Rational Purify against this? It will probably report the problem (possibly buried in a whole lot of other information if this would be the first time you ran such a check on your code base. You will still want to devise a minimal 'main' implementation that exhibits the behaviour to run under a memory and bounds checker

$0.02

PS. just in case, memory corruption bugs usually arise

• by dereferencing stale pointers (after free/delete)
• by writing beyond the end of an allocated buffer
• by freeing/deleting previously pointers (mostly a symptom of bad ownership tracking)

这篇关于_DebugHeapDelete终止访问冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！