VC++ STL Vector problem

[Kemp]

Hi, I'm writing an app in Visual C++ from MSVS2003 and I've come across a really annoying problem that I can't seem to solve. I have a function in one of my classes that takes some data, constructs an object using said data (ie, creates the object and passes the data in for it to use) and then add it to a vector the holds all the objects created by the function. Problem is that my app falls over and dies in a way that windows ends up having to catch.

I narrowed it down to the line which adds the new object to the vector by commenting out the lines one by one until it didn't die anymore. My initial assumption was I was using a crazy pointer somewhere which is usually the cause for such a problem, thing is that the app doesn't actually die on that line. The object *appears* to get added fine, it is when the function returns that it dies, but only if the adding is attempted. The fact that the code after that point executes fine and the attempt to return fails leads me to believe that I am somehow managing to mess up the stack, but as far as I can tell, adding an object to a vector can't actually do that (or shouldn't be able to if you trust that a standard library works properly).

Any thoughts on this?

[Colonel Kernel]

I think you need to post the offending code (or at least a simple test case that can repro the problem). There may be something at work that is only tangentially related to the vector.

[Kemp]

Hmmm.... doubt I can post the code itself as it's part of my final year CS project and I don't think the Uni would take too kindly to people directly helping with the code. I'll see if I can find the smallest general case that still kills it.

[Solar]

Make sure you understand what you're doing when adding an object to a vector. You are storing a copy of the object, not a pointer. Make sure your copy contructor does its stuff correctly. Note that a vector might be realloc'ed as it grows.

[Kemp]

Hmmm.... my number of points of possible failure have expanded to two, I found a second line that when commented out will stop the app from killing itself. As this second one is calling a method written by me I'll be concentrating on this as the more likely one for the moment.


Edit:
Of course, when I try the same in the full version of the code the app still dies... I think there's something fundamentally wrong with the code, though I really hope there's not.

[Solar]

You know the difference between shallow copy and deep copy, do you?

[Kemp]

Yeah, shallow copy makes a copy of the object and only that object, any pointers are left pointing to wherever they already were. Deep copy makes a copy of anything pointed to.

I don't think that's the problem currently, but I suppose it's as good an idea as any as all my debugging steps make the problem seem less rational and more "it just doesn't want to work".

[Kemp]

Just to add to the available pool of random information... On my original code (I gave up trying the stripped down version, the problem shifted around enough to make it almost irrevevant to it) I had the objec that was pushed onto the vector created locally (if it's doing a copy to push then it shouldn't matter that the original is destroyed later). This dies on the return statement with stack corruption suspected. I tried changing it to be created elsewhere with the 'new' operator just to see if moving it somewhere else would produce different results, it does. If I don't delete the object after pushing then it'll push the first one attempted and return afterwards, but the second time the method is called it dies on the vector push statement. If I do delete the object after pushing it (as I'm meant to) then it pushes fine as above but dies on the delete statement following the push.

I'm pretty lost really. If it helps your case Solar, the object being created does contain another object, which contains two other objects.



Edit:
Actually, sorry, it doesn't help your case, the other objects aren't on the end of pointers, they're actually stored within the object in question. The only pointer held by the object is pointing at something that quite a few things in the project hold a pointer to and they really shouldn't have seperate copies of. I'm not worried about concurrency issues currently btw, it's all running in a single thread on a single cpu machine.

[Solar]

Without seeing the code, there's little I can think of to help you. I can suspect two dozen of reasons why it could blow up like that, most of them misuse of referencing and dereferencing operators, faulty constructors and several other things we won't catch without looking at the code. Sorry.

[Kemp]

Yeah, I figured as much. Looks like I'm gonna be on my own for a while, at least you've given me a few hints and pointers (gah, pointers).

Thanks for the help guys, sorry I couldn't help you help me very much.

[Kemp]

A quick refresher course if you don't mind. Am I right in thinking that if you don't explicitly supply a copy constructor then it will just do a direct byte-for-byte copy of the object and use that?

I've fixed a couple of things of potential problems in the code (including one constructor related) but no effect so far. I'm thinking maybe it's the whole object contained within and object contained within an object that is falling apart somewhere down the line, but I can't think of anything immediate that could be causing it, there isn't an inheritence going on (except for the object that is being pushed in the first place, but none of the contained ones have anything like that), or anything of that sort that could be confusing it.

[Colonel Kernel]

What to the destructors of these objects being pushed on the vector actually do?

[Kemp]

What do you mean? The destructors destroy the object when it is no longer needed (either my code calls delete on it or it goes out of scope in the case of local objects). As a copy of the object is pushed on the vector, things I do to my copy should have no effect on the one pushed on (it doesn't hold pointers to anything I destroy).

[Kemp]

Narrowed the problem down to some extent, it appears to actually be related to the contained objects. If I strip out anything that deals with them then it works fine, if I add any of them back then it kills it. I *am* right that

Code: Select all

class Foo
{
private:
    OtherClass Bar;
public:
    Foo();
    ~Foo();
}

would contain Bar as per any other simple variable (int, bool, whatever) and not hold a pointer to a seperately created one somewhere, right?

This is really confusing, especially given that it is killing things that are completely unrelated, which would tend to mean it's dereferencing invalid pointers and writing to the place it finds.

[Solar]

Your assumption on object containment is correct.

But I've seldom seen code where an object is pushed into a vector and afterwards modified. As I've never used such a construct, I'm not sure about its semantics.