passing data, the indicesbuffer, vectors & runtime-error

I’ll take my chance to pop a strictly c/c++ problem … sorry if it’s a problem.
I gather a varied set of indices for minor geometric primitives and they go into the indices-buffer … and a vector of small structs that each holds the parameters for one single draw-call. I use one single but long function to generate it all and uses the vector for the indices-buffer as a reference (not a pointer) as a function-parameter. I start out declaring a couple of auxillery vectors (of unsigned int) to hold indices before I stuff it into the indices-buffer-vector [it will later on be called as the data-pointer indices.data() when it needs to be sent to the graphics-card, no problem].
The function throws a runtime-error … something about “cannot deallocate vector”. Which vector I don’t know, but it’s previously been somewhat associated with the auxillery vectors. When following the debug-trace I’m pointed to the end of the function and not to a particular code-line.
To tighten up on the vector-stuff I’ve moved declarations of the auxillery vectors to the start of the function, and initiated them with there sizes.
When I work on say a pyramid, I collect the key indices (first, count, lowest etc) in the draw-parameters struct, and the indices for the points into the auxillery before taking them further to the large indices-buffer … it’s nitty gritty and easy to get lost, and that’s how I cope …
I don’t clear or delete any vectors. And I’ve switched from using push_back() to initiate the final size and use vector.at() though the problem does not seem like overflow.
The code worked (static arrays & pointers) before switching to pass-by-ref & vectors …
I havn’t got the foggiest clue of what is wrong.
If I should get passed the runtime-error, nothing shows up on the screen - I cannot debug this until I ‘fixed’ the other part. It could be a symptom that the data I generate does not stick all the way to the final buffers.
I hope that one of you may recognize a newbi-error somewhere. (I’m not writing this at home where the code is)

cheers

First of all you are certainly asking at the wrong place and this is for sure not an “advanced” OpenGL question. Secondly a bunch of text does not help to find your bug, because you are just describing what you think you are doing, but the problem is that you are implicitly doing stuff which you don’t intend to do ; )

Nevertheless i can give you the hint that the problem occurs within the destructor of one of your objects, which gets invoked at the end of your function.

yes, but what?
As for the destructor it’s called implictly … and it’ll have to take an advanced programmer to figure out why it cannot go through with the deletion.

void myFunc( vector<unsigned int>& myVRef ){
myVRef.resize(1500) ;
int accum = 0;
vector<unsigned int> auxV1(30);
vector<unsigned int> auxV2(45);
//fill auxV1
for(int i = 0; i<auxV1.size() , i++)
{
myVRef[accum+i] = auxV1;
}
accum +=auxV1.size();
// fill next aux
// accumulate it in myVRef

//steps repeted
}

The (wellworking) code started out using fixed size arrays as auxillery instead of vectors.
The compiler gives no warning hints at compiletime. Doesn’t the pseudo-code look innosent enough? It’s not complicated.

I suppose that it’ll be one of those ‘uninitiated pointer’-problems somewhere in my large code that just pops an impossible error … at an impossible place … ;o/

the debug trace has 14 lines starting in main. At 6.th line I can click to end of the function. Above, the link-ref goes to the vector_allocator lib. The last 6 has a ?() and function-names with indication of their 32/64 bit origin. One of these is wow64 … pretty misplaced in among all the 32-functions?