Memory Allocation Error Caused by Inserting into std::vector

Question

As part of a university project I'm writing a text editor from scratch. I'm having issues with the code I've written to build an maintain the core data structure.

Below is my Sourcecode, the error gcc/g++ is giving me, and the stacktrace I got from gdb. I go into more detail about my design below all of that.

Yes, I do feel bad for all the printing and verbose declarations in Document::insertChar. I thought it might be an initialisation issue at first. And I'm still learning the reins with gdb.

Importantly though, temp.push_back(lnd); and Lines.insert(iter, nline); (lnd was originall nLine) both cause the same error.

Sourcecode

Document.cpp : http://pastebin.com/LgGHmir8
Line.cpp : http://pastebin.com/BBhbnxUt

(code never tested on a non Linux platform, builds with g++ may not with other compilers)

Error:

test: malloc.c:2388: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *(sizeof(size_t))) - 1)) & ~((2 *(sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. Aborted (core dumped)

Stacktrace:

(gdb) backtrace
#0  0x00007ffff71d45f8 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff71d5a7a in abort () from /usr/lib/libc.so.6
#2  0x00007ffff7218468 in __malloc_assert () from /usr/lib/libc.so.6
#3  0x00007ffff721a056 in sysmalloc () from /usr/lib/libc.so.6
#4  0x00007ffff721b0a6 in _int_malloc () from /usr/lib/libc.so.6
#5  0x00007ffff721c3d4 in malloc () from /usr/lib/libc.so.6
#6  0x00007ffff7ae70e8 in operator new (sz=24) at /build/gcc/src/gcc-5.3.0/libstdc++-v3/libsupc++/new_op.cc:50
#7  0x0000000000401f15 in __gnu_cxx::new_allocator<Line>::allocate (this=0x7fffffffe950, __n=1) at /usr/include/c++/5.3.0/ext/new_allocator.h:104
#8  0x0000000000401d9e in __gnu_cxx::__alloc_traits<std::allocator<Line> >::allocate (__a=..., __n=1) at /usr/include/c++/5.3.0/ext/alloc_traits.h:182
#9  0x0000000000401b90 in std::_Vector_base<Line, std::allocator<Line> >::_M_allocate (this=0x7fffffffe950, __n=1) at /usr/include/c++/5.3.0/bits/stl_vector.h:170
#10 0x0000000000401654 in std::vector<Line, std::allocator<Line> >::_M_insert_aux (this=0x7fffffffe950, __position=<error reading variable: Cannot access memory at address 0x0>, 
__x=...) at /usr/include/c++/5.3.0/bits/vector.tcc:353
#11 0x000000000040139e in std::vector<Line, std::allocator<Line> >::push_back (this=0x7fffffffe950, __x=...) at /usr/include/c++/5.3.0/bits/stl_vector.h:925
#12 0x0000000000400fff in Document::insertChar (this=0x7fffffffe9b0, chr=10 '\n') at Document.cpp:67
#13 0x00000000004011be in main (argc=1, argv=0x7fffffffeae8) at Document.cpp:204

A brief introduction to the design the thing, I am using a std::vector to hold lines (mainly for convenience). And the class Line, which is similar to vector, it's an imlementation of a dynamic array. The reason for this is I will eventually be holding line metadata in there.

Vector seems to not like it when I try to use insert to insert a Line. Actually, beyond the Document::Document(). Any time I try inserting a Line object into a vector, whether it be push_back or insert. It fails.

I... Don't quite understand why, and would like to. Failing that - I am just going to have to implement my own version so I at least understand what's going on. (Shame you can't get O(1) on insert and search operations... A linked list would have been nice if I didn't need fast searching...)

Answer 1

Okay, had some sleep. Came back to this.

delete [] mData is called in the copy constructor. mData is initialised as NULL in the copy constructor's initialisation list. So that was problem A. More importantly;

std::copy(ln.mData, **mData**+mCapacity, mData);

No idea what memory address mData would be at at that point. But it's sure as hell not what was intended. This is the root of the allocation issue. Thanks to the person who directed me to look at the copy constructor.