Access violation using LocalAlloc()

Question

I have a Visual Studio 2008 Windows Mobile 6 C++ application that is using an API that requires the use of LocalAlloc(). To make my life easier, I created an implementation of a standard allocator that uses LocalAlloc() internally:

/// Standard library allocator implementation using LocalAlloc and LocalReAlloc 
/// to create a dynamically-sized array. 
/// Memory allocated by this allocator is never deallocated. That is up to the
/// user.
template< class T, int max_allocations > 
class LocalAllocator
{
public:
    typedef T         value_type;
    typedef size_t    size_type;
    typedef ptrdiff_t difference_type;
    typedef T*        pointer;
    typedef const T*  const_pointer;
    typedef T&        reference;
    typedef const T&  const_reference;

    pointer address( reference r ) const { return &r; };
    const_pointer address( const_reference r ) const { return &r; };

    LocalAllocator() throw() : c_( NULL )
    {
    };

    /// Attempt to allocate a block of storage with enough space for n elements
    /// of type T. n>=1 && n<=max_allocations.
    /// If memory cannot be allocated, a std::bad_alloc() exception is thrown.
    pointer allocate( size_type n, const void* /*hint*/ = 0 )
    {
        if( NULL == c_ )
        {   
            c_ = LocalAlloc( LPTR, sizeof( T ) * n );
        }
        else
        {
            HLOCAL c = LocalReAlloc( c_, sizeof( T ) * n, LHND );
            if( NULL == c )
                LocalFree( c_ );
            c_ = c;
        }
        if( NULL == c_ )
            throw std::bad_alloc();
        return reinterpret_cast< T* >( c_ );
    };

    /// Normally, this would release a block of previously allocated storage.
    /// Since that's not what we want, this function does nothing.
    void deallocate( pointer /*p*/, size_type /*n*/ )
    {
        // no deallocation is performed. that is up to the user.
    };

    /// maximum number of elements that can be allocated
    size_type max_size() const throw() { return max_allocations; };

private:
    /// current allocation point
    HLOCAL c_;
}; // class LocalAllocator

My application is using that allocator implementation in a std::vector<>

#define MAX_DIRECTORY_LISTING 512

std::vector< WIN32_FIND_DATA, 
    LocalAllocator< WIN32_FIND_DATA, MAX_DIRECTORY_LISTING > > file_list;

WIN32_FIND_DATA find_data = { 0 };
HANDLE find_file = ::FindFirstFile( folder.c_str(), &find_data );
if( NULL != find_file )
{
    do 
    {
        // access violation here on the 257th item.
        file_list.push_back( find_data );
    } while ( ::FindNextFile( find_file, &find_data ) );

    ::FindClose( find_file );
}

// data submitted to the API that requires LocalAlloc()'d array of WIN32_FIND_DATA structures
SubmitData( &file_list.front() );

On the 257th item added to the vector<>, the application crashes with an access violation:

Data Abort: Thread=8e1b0400 Proc=8031c1b0 'rapiclnt'
AKY=00008001 PC=03f9e3c8(coredll.dll+0x000543c8) RA=03f9ff04(coredll.dll+0x00055f04) BVA=21ae0020 FSR=00000007
First-chance exception at 0x03f9e3c8 in rapiclnt.exe: 0xC0000005: Access violation reading location 0x01ae0020.

LocalAllocator::allocate is called with an n=512 and LocalReAlloc() succeeds. The actual Access Violation exception occurs within the std::vector<> code after the LocalAllocator::allocate call:

     0x03f9e3c8    
     0x03f9ff04    
>    MyLib.dll!stlp_std::priv::__copy_trivial(const void* __first = 0x01ae0020, const void* __last = 0x01b03020, void* __result = 0x01b10020) Line: 224, Byte Offsets: 0x3c    C++
     MyLib.dll!stlp_std::vector<_WIN32_FIND_DATAW,LocalAllocator<_WIN32_FIND_DATAW,512> >::_M_insert_overflow(_WIN32_FIND_DATAW* __pos = 0x01b03020, _WIN32_FIND_DATAW& __x = {...}, stlp_std::__true_type& __formal = {...}, unsigned int __fill_len = 1, bool __atend = true) Line: 112, Byte Offsets: 0x5c    C++
     MyLib.dll!stlp_std::vector<_WIN32_FIND_DATAW,LocalAllocator<_WIN32_FIND_DATAW,512> >::push_back(_WIN32_FIND_DATAW& __x = {...}) Line: 388, Byte Offsets: 0xa0    C++
     MyLib.dll!Foo(unsigned long int cbInput = 16, unsigned char* pInput = 0x01a45620, unsigned long int* pcbOutput = 0x1dabfbbc, unsigned char** ppOutput = 0x1dabfbc0, IRAPIStream* __formal = 0x00000000) Line: 66, Byte Offsets: 0x1e4    C++

If anybody can point out what I may be doing wrong, I would appreciate it.

Thanks, PaulH

Answer 1

I'm not sure how this is supposed to work. When you allocate each next block, you free the currently used block. So all the pointers that pointed there become invalid. I doubt this is what vector expects from an allocator.

Answer 2

I first thought your problem was the parameter LHND to LocalReAlloc() -- you should usually not pass that parameter to that function.

The actual problem is that you should not even be calling that function. The vector implementation reallocates its own memory. A C++ standard allocator does not provide reallocation.

You should implement:

template<typename T> class LocalAllocator {
...
pointer allocate(sizetype s)
{
    pointer p = reinterpret_cast<pointer>(LocalAlloc(LPTR, s * sizeof(T)));

    if (NULL == p)
        throw std::bad_alloc();

    return p;
}

void deallocate(pointer p, sizetype)    
{
    LocalFree(reinterpret_cast<LHND>(p));
}
...
}

Something similar to that should work.

There is no need for you to keep track of the pointer -- it will be provided back to you at a call to deallocate(), that is the responsibility of your API client, the vector<T> implementation.

Answer 3

To expand on Igor Krivokon's answer, each call to allocate() possibly invalidates all the pointers returned by previous calls to allocate(). This is not how an allocator is supposed to work and will most probably result in undefined behavior:

For example when the vector needs to allocate a new bigger piece of memory, it will copy the data from the "old" memory to the "new" one returned by allocate(). Then it will destroy all the objects in the "old" memory and free it.

If old and new now are the same memory locations, copy construction of the "new" objects and the following destruction of the "old" objects will get all messed up. On the other hand, if old is not valid anymore (because it got reallocated), the vector will access invalid memory.

And another point: Allocators have to be copy-constructible. If a copy is constructed from your allocator and then both are used to allocate further elements, LocalReAlloc() will be called on the same pointer twice. So you would need to provide a custom copy constructor that avoids this kind of problems.