Stack unwind clobbering memory with inplace new operator

Question

I have a pretty nasty bug that has been bothering for a while. Here's the situation, I'm creating an in memory filesystem. I have pre-allocated data blocks for each file in which to do reads and writes from. To implement directories I have a simple std::vector object containing all the files in the directory. This vector object is at the top of the file in each directory. Therefore, in order to read and write from the directory I read the first 16 bytes into a character buffer and type cast it as a vector (16 bytes because sizeof(vector<T>) is 16 on my system). Specifically, the first 16 bytes are not elements of the vector, but the vector itself. However, the vector is somehow being clobbered after I exit out of a key function.

The following code does not throw an exception and can correctly save a vector to a character buffer to be later retrieved.

#include <vector>
char dblock[16];

typedef std::vector<int> Entries;
void foo() {
    char buf[sizeof(Entries)];
    Entries* test = new (buf)Entries();
    test->push_back(0);
    for (int i = 0; i < sizeof(std::vector<int>); ++i) {
        dblock[i] = buf[i];
    }
}

void bar() {
    char buf[sizeof(Entries)];
    for (int i = 0; i < sizeof(std::vector<int>); ++i) {
        buf[i] = dblock[i];
    }
    Entries* test = (Entries*)buf;
    test->back();
}

int main()
{
    foo();
    bar();
    return 0;
}

However, once the function foo is changed to include an argument like so, any time I try to use iterators an exception is thrown.

void foo(int this_arg_breaks_everything) {
    char buf[sizeof(Entries)];
    Entries* test = new (buf)Entries();
    test->push_back(0);
    for (int i = 0; i < sizeof(std::vector<int>); ++i) {
        dblock[i] = buf[i];
    }
}

Looking at the disassembly, I found the problem assmbler when the function is tearing down its frame stack:

add         esp,128h  <----- After stack is reduced, vector goes to an unusable state.
cmp         ebp,esp  
call        __RTC_CheckEsp (0D912BCh)  
mov         esp,ebp  
pop         ebp  
ret

I found this code by using the debugger to test if ((Entries*)dblock)->back() returns an exception or not. Specifically the exception is "Access violation reading location 0XCCCCCCCC". The location in question is std::vector's std::_Container_base12::_Myproxy->_Mycont->_Myproxy == 0XCCCCCCCC; you can find it at line 165 of xutility.

And yes, the bug only happens when the inplace new operator is used. Using a normal new operator then writing test to dblock doesn't throw an exception.

Thus, I came to the conclusion that the ultimate reason for this is somehow the compiler is doing a bad stack unwind clobbering some part of memory that it shouldn't be.

Edit: Changed wording for clarity sake. Edit2: Explained magic numbers.

Answer 1

In visual studio 2013 this generates errors and after taking a look at the internal data of the vector it was pretty easy to figure out why. Vector allocates an internal object that does a lot of it's heavy lifting, this internal object in turn stores a pointer back to the vector and thus knows the location that the vector is supposed to be. When the vector's memory is moved from one location to another, the memory it occupies changes and thus that internal object now instead points back to memory that later gets wiped by debug code.

Looking at your code, this looks like the exact same thing. std::_Container_base12 is a base class used by the vector which has a member called myProxy. myProxy is an internal object that does heavy lifting, and has a pointer back to the vector that contains it. When you move the vector, you can't update this pointer and so when you go to use the vector data that was moved it tries to use myProxy which is still trying to refer back to the original vector location which was wiped. Because that data area was wiped, it looks for a pointer in it and instead finds 'CCCCCCCC' which is what the debug code does to memory data that was wiped. It tries to access that memory location and everything explodes.

Answer 2

What you are doing (serializing an opaque C++ object with the equivalent of memcpy to a local buffer) is not going to work sustainably because vector objects are deep objects with lots of pointers to heap memory. Nevertheless to answer your question, why you are getting a crash.

The problem is alignment. When you try doing

char buf[sizeof(Entries)];
Entries* test = new (buf)Entries();

this assumes that buf has the proper alignment for the object Entries. I am not going to claim to know the internal structure of vector, but I bet it looks something like

class vector
{
  T* start;
  T* end;
  other stuff
}

i.e. it is a bunch of pointers to heap. Pointers require register alignment, which is 8 bytes on a 64-bit machine. Alignment by N bytes means you can divide the address evenly by N. However, you are allocating buf on the stack, which is not guaranteed to have any alignment, but probably accidentally has 8 byte alignment because it is the only thing on your local stack frame. However, if you declare an argument to foo, and the argument is say an int which is 4 bytes, then buf is no longer 8-byte aligned since you've just added 4 bytes. Then when you try to access the pointers that are unaligned, you get your crash.

As an experiment, try changing foo to

void foo(int unused1, int unused2) {

This might accidentally realign buf, and it might not crash. However, stop what you are doing and don't do it this way.

See http://en.wikipedia.org/wiki/Data_structure_alignment for more info and this for guidance on serializing: http://www.parashift.com/c++-faq/serialization.html . You might consider a Boost vector class that is serializable.

Answer 3

Why not just write the following?

std::vector<int> dblock;

void foo() {
    dblock.push_back(0);
}

void bar() {
    dblock.back();
}

Answer 4

Simplest answer for this: UNDEFINED BEHAVIOR.

std::vector isn't trivially copyable, you can't memcpy it from one place to another.

Another problem with your code is that dblock could have different alignment than std::vector. This could cause crash on some processors.

Third problem is compiler sometime could return garbage when you copy buff to dblock. Its because you break strict aliasing rule.