I have a function, which returns a vector.
vector<Cell> buildTree(Bodies & bodies) {
...
vector<Cell> cells(1);
cells.reserve(bodies.size());
buildCells(&bodies[0], &buffer[0], 0, bodies.size(), &cells[0], cells, X0, R0);
return cells;
When debugging, the vector has size 1 after buildCells when the error happens. After the return, the vector in the function is destroyed as you would expect, but then the program hangs. When pausing the attached process, it seems to have an endless loop at xmemory0 of the Microsoft Visual Studio 2015 compiler:
// TEMPLATE FUNCTION _Destroy_range WITH ALLOC
template<class _Alloc,
class _Ptr = typename _Wrap_alloc<_Alloc>::pointer> inline
void _Destroy_range1(_Ptr _First, _Ptr _Last, _Wrap_alloc<_Alloc>& _Al, false_type)
{ // destroy [_First, _Last), no special optimization
for (; _First != _Last; ++_First)
_Al.destroy(_Unfancy(_First));
}
In the stacktrace is the size of the vector at the return statement now 0 and _Last
in the _Destroy_range1
function is a pointer to a Cell
struct with uninitialized data while _First
is an invalid pointer.
When stepping through the loop, it seems to be stuck at this for-loop. I am not absolutely sure, but _First
keeps pointing at invalid memory addresses and the loop does not terminate after a lot of steps (while I would expect it to terminate after one step).
The Cell
struct does not contain anything with a fancy destructor, but plain datatypes, other vectors and a class with an empty destructor function.
Source of the function, Source of the data types
I had the same problem before with push_back and the Body
destructor in this code:
exafmm::Bodies particle_bodies;
for(size_t i = 0; i < particles.size(); i++) {
exafmm::vec3 X;
for(short j = 0; j < 3; j++) { X[j] = particles[i][j]; };
particle_bodies.push_back(exafmm::Body{X, 0, 0, 0, i});
}
which could be solved by allocating the Bodies (vector) first and then assigning the elements instead of using push_back.
Aucun commentaire:
Enregistrer un commentaire