为什么在尝试使用地图时出现访问冲突

Question

I have a class here meant to log where memory is mapped. When I set a specific location on the map to some number, it give me an access violation.

The exact error is Exception thrown at 0x003A5B4B in memorymapperexample.exe: 0xC0000005: Access violation reading location 0x00000004.

This is my class. Addpair and clearlocation give errors when called. The map key is a void pointer and the map value is a int. I don't understand why this simple thing is not working.

#include <map>
#include <unordered_map>
#include <string>
#include <iostream>
#include <memory>

using namespace std;


template <typename T>
class MallocAllocator
{
private:
    map<void *, int> ord;
    int total;
public:
    typedef T value_type;
    MallocAllocator() { }
    template <typename U> MallocAllocator(const MallocAllocator<U>& other) {}
    T* allocate(size_t count)
    {
        return (T*)malloc(count * sizeof(T));
    }
    void deallocate(T* object, size_t n)
    {
        void* ptr = reinterpret_cast<void*>(object);
        free(ptr);

    }
    void addpair(void* a, int b)
    {
        ord[a] = b; //ERROR HERE
    }

    void clearlocation(void * a)
    {
        ord[a] = 0; //ERROR HERE TOO
    }
};

MallocAllocator<void*> memoryManager;

void* operator new(size_t size)
{
    cout << "Allocating memory..." << endl;
    auto newObject = memoryManager.allocate(size);

    memoryManager.addpair(newObject, size);
    memoryManager.clearlocation(newObject);
    return newObject;
}

void operator delete(void* objectPtr) noexcept
{
    cout << "DEAllocating memory..." << endl;
    void** ptr = reinterpret_cast<void**>(objectPtr);
    memoryManager.deallocate(ptr, 0);
    //free(objectPtr);
}



int main()
{
    int * ima = new int(99);
    delete ima;
    return 1;
}

Answer 1

Found your problem. Running it through VS gave me this stack trace.

bleh.exe!std::_Tree<std::_Tmap_traits<void * __ptr64,int,std::less<void * __ptr64>,std::allocator<std::pair<void * __ptr64 const,int> >,0> >::_Lbound<void * __ptr64>(void * const & _Keyval) Line 2090 C++
bleh.exe!std::_Tree<std::_Tmap_traits<void * __ptr64,int,std::less<void * __ptr64>,std::allocator<std::pair<void * __ptr64 const,int> >,0> >::lower_bound(void * const & _Keyval) Line 1549 C++
bleh.exe!std::map<void * __ptr64,int,std::less<void * __ptr64>,std::allocator<std::pair<void * __ptr64 const,int> > >::_Try_emplace<void * __ptr64 const & __ptr64>(void * const & _Keyval) Line 210    C++
bleh.exe!std::map<void * __ptr64,int,std::less<void * __ptr64>,std::allocator<std::pair<void * __ptr64 const,int> > >::try_emplace<>(void * const & _Keyval) Line 230   C++
bleh.exe!std::map<void * __ptr64,int,std::less<void * __ptr64>,std::allocator<std::pair<void * __ptr64 const,int> > >::operator[](void * const & _Keyval) Line 339  C++
bleh.exe!MallocAllocator<void * __ptr64>::addpair(void * a, int b) Line 80  C++
bleh.exe!operator new(unsigned __int64 size) Line 97    C++
[External Code] 
bleh.exe!MallocAllocator<void * __ptr64>::MallocAllocator<void * __ptr64>() Line 66 C++
bleh.exe!`dynamic initializer for 'memoryManager''() Line 89    C++
[External Code] 

The stack reveals that the program is in the initialization of memoryManager when something calls new (I guess std::map is trying to allocate something). But of course, you've overloaded new to use memoryManager which has not been fully initialized yet! Bummer. And it throws the error when trying to get the root node of the std::map which doesn't give a sensible value.

Debugging is an enormously useful skill.

Edit: compiling with g++ -std=c++11 bleh.cpp and running through gdb gives me a different but equally troubling result.

#0  0x00007ffff756a648 in _IO_new_file_xsputn (f=0x7ffff78b0400 <_IO_2_1_stdout_>, data=0x402597, n=20) at fileops.c:1320
#1  0x00007ffff755fe6d in __GI__IO_fwrite (buf=<optimized out>, size=1, count=20, fp=0x7ffff78b0400 <_IO_2_1_stdout_>) at iofwrite.c:43
#2  0x00007ffff7b7f63e in std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long) ()  from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff7b7f947 in std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x0000000000400d11 in operator new(unsigned long) ()
#5  0x000000000040228b in __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<void* const, int> > >::allocate(unsigned long, void const*) ()
#6  0x0000000000402142 in std::allocator_traits<std::allocator<std::_Rb_tree_node<std::pair<void* const, int> > > >::allocate(std::allocator<std::_Rb_tree_node<std::pair<void* const, int> > >&, unsigned long) ()
#7  0x0000000000401d75 in std::_Rb_tree<void*, std::pair<void* const, int>, std::_Select1st<std::pair<void* const, int> >, std::less<void*>, std::allocator<std::pair<void* const, int> > >::_M_get_node() ()
#8  0x00000000004015cd in std::_Rb_tree_node<std::pair<void* const, int> >* std::_Rb_tree<void*, std::pair<void* const, int>, std::_Select1st<std::pair<void* const, int> >, std::less<void*>, std::allocator<std::pair<void* const, int> > >::_M_create_node<std::piecewise_construct_t const&, std::tuple<void* const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple<void* const&>&&, std::tuple<>&&) ()
#9  0x0000000000401368 in std::_Rb_tree_iterator<std::pair<void* const, int> > std::_Rb_tree<void*, std::pair<void* const, int>, std::_Select1st<std::pair<void* const, int> >, std::less<void*>, std::allocator<std::pair<void* const, int> > >::_M_emplace_hint_unique<std::piecewise_construct_t const&, std::tuple<void* const&>, std::tuple<> >(std::_Rb_tree_const_iterator<std::pair<void* const, int> >, std::piecewise_construct_t const&, std::tuple<void* const&>&&, std::tuple<>&&) ()
#10 0x0000000000401122 in std::map<void*, int, std::less<void*>, std::allocator<std::pair<void* const, int> > >::operator[](void* const&) ()
#11 0x0000000000400ee4 in MallocAllocator<void*>::addpair(void*, int) ()
#12 0x0000000000400d4a in operator new(unsigned long) ()
#13 0x000000000040228b in __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<void* const, int> > >::allocate(unsigned long, void const*) ()
#14 0x0000000000402142 in std::allocator_traits<std::allocator<std::_Rb_tree_node<std::pair<void* const, int> > > >::allocate(std::allocator<std::_Rb_tree_node<std::pair<void* const, int> > >&, unsigned long) ()
#15 0x0000000000401d75 in std::_Rb_tree<void*, std::pair<void* const, int>, std::_Select1st<std::pair<void* const, int> >, std::less<void*>, std::allocator<std::pair<void* const, int> > >::_M_get_node() ()
#16 0x00000000004015cd in std::_Rb_tree_node<std::pair<void* const, int> >* std::_Rb_tree<void*, std::pair<void* const, int>, std::_Select1st<std::pair<void* const, int> >, std::less<void*>, std::allocator<std::pair<void* const, int> > >::_M_create_node<std::piecewise_construct_t const&, std::tuple<void* const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple<void* const&>&&, std::tuple<>&&) ()
#17 0x0000000000401368 in std::_Rb_tree_iterator<std::pair<void* const, int> > std::_Rb_tree<void*, std::pair<void* const, int>, std::_Select1st<std::pair<void* const, int> >, std::less<void*>, std::allocator<std::pair<void* const, int> > >::_M_emplace_hint_unique<std::piecewise_construct_t const&, std::tuple<void* const&>, std::tuple<> >(std::_Rb_tree_const_iterator<std::pair<void* const, int> >, std::piecewise_construct_t const&, std::tuple<void* const&>&&, std::tuple<>&&) ()
#   ... ad inifintum ...

This time, the program is setting up one of its streams std::cout by the looks of it. And tries to allocate memory. Looks like memoryManager happened to be set up right or actually initialized properly. Either way when it tries to allocate something your allocator causes a new node to be created in std::map . Which requires memory allocation. Which requires creating a new node... See where I'm going with this? The stack trace repeats like this for quite a while.

All in all, std::map is a bad internal structure to use for this. (Actually most of the standard containers would cause similar problems).