Unhandled exception at 0x00423e3b in memory_manager.exe: 0xC0000005: Access violation reading location 0x00000004.<\/p>\n
Souce file Download: http:\/\/www.cppblog.com\/Files\/mymsdn\/memory_manager_bug_vs2008_debug.zip Hey,<\/p>\n
I am trying create a memory manager function to resolve some problem:<\/p>\n
I have writen the memory_manager class to manage allocate and deallocate a block of memory. interface:<\/p>\n
void *allocate(size_t size); \nBOOL deallocate(void * ptr); \n\/\/ ... \n<\/code><\/pre>\nI am trying to create a placement new to replace the new from the system, so I add the code below to do this.<\/p>\n
#ifdef _DEBUG \n\n\nstatic memory_manager mm; \n\n\ninline void * __cdecl operator new(unsigned int size, \n const char *file, int line) \n{ \n void * res; \n if((res = mm.allocate(size)) == 0) \n { \n \/\/ go to default allocator \n } \n return res; \n}; \n\n\ninline void __cdecl operator delete(void *p) \n{ \n if(!mm.deallocate(p)) \n return; \n}; \n\n\ninline void __cdecl operator delete[]( void * p ) \n{ \n if(!mm.deallocate(p)) \n return; \n}; \n#endif \n\n\n#ifdef _DEBUG \n#define DEBUG_NEW new(__FILE__, __LINE__) \n#else \n#define DEBUG_NEW new \n#endif \n#define new DEBUG_NEW \n<\/code><\/pre>\nBut I encountered the exception in runtime, “Unhandled exception at 0x00423e3b in memory_manager.exe: 0xC0000005: Access violation reading location 0x00000004.”.<\/p>\n
My memory_manager code has used the STL code to manage my manager structures.<\/p>\n
I debug my code and step into the STL code, I found it used the CRT malloc to assign memory, after deconstruct the static variable “memory_manager mm”, system throw the unhandled exception.<\/p>\n
Questions:<\/p>\n
I don’t know how to improve my code to use the placement new \/ replace the new to my code?<\/p>\n
I don’t know what has happened in deconstruct the static variable?<\/p>\n
I don’t know is any better way to resolve my problems metion in the begining of this post?<\/p>\n
I have a thinking about create a shared_ptr to deal with it, may be like this:<\/p>\n
shared_ptr sp_(new MyClass); \n\/\/ inner of shared_ptr: \n\n\/\/ 1. new MyClass use the system allocator to assign memory. \n\n\/\/ 2. In the constructor of the shared_ptr: \n\n\/\/ 2.1 copy the memroy of the (new MyClass) object into our memory: \n\n\/\/ static memory_manager mm; \n\n\/\/ void * p = mm.allocate(sizeof obj); \n\n\/\/ memmove( from obj to p); \n\n\/\/ delete obj; \n\n\/\/ return p; \n\n\/\/ 3. Is it right? \n\n\/\/ 4. if it's a array, like new MyClass[10]; we must delete the object \n<\/code><\/pre>\nlike this delete [] obj ? How to difference it?<\/p>\n
Thanks!<\/p>\n
\n- \n
The problem is that you’re overloading the global operator delete<\/code> and and operator delete[]<\/code> in memory_manager_main.cpp<\/code>. As a general guideline, if you overload one of the new<\/code> or delete<\/code> operators, you should most likely have to implement overloads for all.<\/p>\nThen internally in your memory manager class you’re using std::map<\/code> and std::multimap<\/code>, both of which relies on the std::allocator<\/code> class unless you specify otherwise. This, at least for the version Microsoft provides with Visual Studio, relies on operator delete<\/code>\/operator new<\/code> for deallocations and allocations.<\/p>\nI’m not sure, but you might either be ending up deleting things with the wrong delete, or you’re trying to delete stuff with operator delete in std::map<\/code>‘s destructor using operator delete<\/code>, that relies on the instance of the class you’re deleting?<\/p>\nYou could possibly implement your own allocator using malloc<\/code>\/free<\/code> to get around this problem.<\/p>\n<\/li>\n- \n
\n\n- reference count the new \/ delete counter when allocate memory to anaylize the memory leak problem.<\/li>\n<\/ol>\n<\/blockquote>\n
I’m pretty sure that MSVC already comes with debug memory allocator which allows to detect such issues. IIRC it can be optionally activated for debug builds.<\/p>\n
In fact, when searching for “visual studio memory debugger” first link leads immediately to this page: Memory Leak Detection Enabling.<\/p>\n
\n\n- reduce the memory fragment.<\/li>\n<\/ol>\n<\/blockquote>\n
Standard memory allocators are quite resistant to memory fragmentation. You might need alternative memory allocator only if you write application which is expected to run months\/years without interruption. But even for the cases replacement of memory allocator is superficial and less reliable compared to the simple resource allocation in advance: allocate all resources which might be needed right after the start of the application.<\/p>\n
\nI don’t know how to improve my code to use the placement new \/ replace the new to my code?<\/p>\n<\/blockquote>\n
You do not need to do anything special. Placement new<\/code> doesn’t trigger memory allocation – it is just a fancy way to call a constructor on a piece of raw memory. If the raw memory was allocated before with the new<\/code> then you are all set already.<\/p>\n\nI don’t know what has happened in deconstruct the static variable?<\/p>\n<\/blockquote>\n
No memory management is involved. Static variables live in data segment, not in heap.<\/p>\n
\nI don’t know is any better way to resolve my problems metion in the begining of this post?<\/p>\n<\/blockquote>\n
My wild guess would be (and this is a usual beginner’s error) is that your implementation of memory manager uses dynamic memory and is recursively calling itself.<\/p>\n<\/li>\n<\/ol>\n
Originally posted 2013-11-27 11:51:39. <\/small><\/p>","protected":false},"excerpt":{"rendered":"
Unhandled exception at 0x00423e3b in memory_manager.exe: 0xC0000005: Access violation reading location 0x00000004. Souce file Download: http:\/\/www.cppblog.com\/Files\/mymsdn\/memory_manager_bug_vs2008_debug.zip Hey, I am trying create a memory manager function to resolve some problem: reference count the new \/ delete counter when allocate memory to anaylize the memory leak problem. reduce the memory fragment. I have writen the memory_manager class […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1560","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/1560","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=1560"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/1560\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=1560"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=1560"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=1560"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}