Copying memory, pointers and the like.

**grumpy** · 12-09-2006

Originally Posted by dwks

Why don't you try something like this?

Code:

class CLASS_1{
    public:
    DataClass *data;

    CLASS_1(){
        data = NULL;
    }
    ~CLASS_1(){
        delete data;
        data = NULL;
    }
};

class CLASS_2{
    public:
    DataClass *data;
    CLASS_1 *class1;

    CLASS_2(){
        this->data = new DataClass();

        class1 = new CLASS_1();
        class1->data = this->data;
    }
    ~CLASS_2(){
        delete data;
        data = NULL;

        delete class1;
        class1 = NULL;
    }
};

This first example still yields undefined behaviour, because it has the problem of deleting something twice as, at the start of the CLASS_2 destructor, data and class1->data point at the same thing.

Originally Posted by dwks

If you leave that line unchanged and allocate a new DataClass in CLASS_1's constructor, then use it instead of allocating a new one in CLASS_2's constructor.

Code:

class CLASS_1{
    public:
    DataClass *data;

    CLASS_1(){
        data = new DataClass();
    }
    ~CLASS_1(){
        delete data;
        data = NULL;
    }
};

class CLASS_2{
    public:
    DataClass *data;
    CLASS_1 *class1;

    CLASS_2(){
        this->data = new DataClass();

        //class1 = new CLASS_1();
        this->data = class1->data;
    }
    ~CLASS_2(){
        delete data;
        data = NULL;

        delete class1;
        class1 = NULL;
    }
};

In short, to fix your problem, you have to allocate only one DataClass.

This example introduces another problem as, within CLASS_2's constructor, class1 is an uninitialised pointer (it is never initialised). So assigning this->data = class1->data yields undefined behaviour.

**psychopath** · 12-09-2006

Ok, thanks for the help everyone.

I can't seem to figure out what causes the error when using one instance (as opposed to copying all the data). I've eliminated multithreading and any possible issues with using std::vector in this. For now I guess I'll just make copies of the data, since it doesn't seem to increase the overall memory footprint that much anyway.

**Daved** · 12-09-2006

>> data->subclass->vector[data->var].function(); //ERROR
On that line, what is data->subclass->vector.size() and what is data->var?

**psychopath** · 12-09-2006

size() = 1. data->var is always set to 0 (at least for testing purposes).

**Daved** · 12-09-2006

How do you know size is 1, do you output it, check it in the debugger, or do you just know it should be 1?

What does the data variable look like in the debugger's watch? Is its memory address 0x00000000, 0xcdcdcdcd, 0xdeadbeef, or something like that?

**psychopath** · 12-09-2006

I wrote the size to my applications log file.

These are the access violations the debugger gives me:

Originally Posted by VC++ 2005 Express

First-chance exception at 0x00000000 in Clockwork.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x79eea7c3 in Clockwork.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x79eea7c3 in Clockwork.exe: 0xC0000005: Access violation reading location 0x00000000.
A first chance exception of type 'System.AccessViolationException' occurred in Clockwork.exe
First-chance exception at 0x79eea7c3 in Clockwork.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x79eea7c3 in Clockwork.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x79eea7c3 in Clockwork.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x79eea7c3 in Clockwork.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x79eea7c3 in Clockwork.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x79eea7c3 in Clockwork.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x79eea7c3 in Clockwork.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x79eea7c3 in Clockwork.exe: 0xC0000005: Access violation reading location 0x00000000.

**vart** · 12-09-2006

There are too many operations on the single line

data->subclass->vector[data->var].function(); //ERROR

Try to rewrite it in several operations with asserts inbetween

Code:

assert(data);
SUBCLASS* ptr = data->subclass;
assert(ptr);
ITEM item = ptr->vector[data->var];
item.function();

and see where the ERROR occured exactly...

**psychopath** · 12-09-2006

I'm pretty sure the error would have to be occuring in function. data->subclass->vector contains vectors of other classes. function creates a new object in one of those vectors owned by vector. Looking through more debug info, the index of the child vector being set is NULL (0x000...more zero's). That would be causing the access violation. But I still can't seem to figure out why it ends up as NULL, only when pointing to the data class rather than copying it.

**jafet** · 12-09-2006

You'd better show us your DataClass, if possible. As much of it as is needed to demonstrate your problem.

**psychopath** · 12-10-2006

Well, I can't give all of the exact code (there's too much). But I can give a recreation of the problem causing code.

Code:

class DataClass{
    public:
    int var;
    SubClass *subclass;

    DataClass(){
        subclass = new SubClass();
    }
    ~DataClass(){
        delete subclass;
        subclass = NULL;
    }
};

class SubClass{
    public:
    int numVectors;
    std::vector<VectorClass> vector;

    SubClass(){
        numVectors = 0;
    }

    void newVector(){
        vector.reserve(numVectors+1);
        vector.push_back(VectorClass());
        numVectors++;
    }
};

class VectorClass{
    public:
    int numOtherVector;
    std::vector<OtherVectorClass*> otherVector;

    VectorClass(){
        numOtherVector = 0;
    }

    void AddToVector(){ //this is the function that causes the error
        otherVector.resize(numOtherVector+1);
        otherVector[numOtherVector] = new OtherVectorClass();

        numOtherVector++;

        /*otherVector appears to be NULL in the debugger*/
    }
};

And with that code, I would call:

Code:

data->subclass->newVector();

/*other irrelevent code and stuff*/

data->subclass->vector[data->var].AddToVector(); //data->var equals 0

**Daved** · 12-10-2006

>> /*otherVector appears to be NULL in the debugger*/
If otherVector is null there, then that means the VectorClass object is bad. Which means either data->subclass->vector[data->var], data->subclass, or data is bad. Try vart's suggestion and separate it out, checking each pointer to verify that it is valid.

**psychopath** · 12-11-2006

Look at this line:

Code:

std::vector<OtherVectorClass*> otherVector;

If OtherVectorClass inherits from other classes (which may also inherit from other classes), how to I go about figuring out which class is causing the problems. Or would it have to be the top-level class that I make the pointer to (in this case, OtherVectorClass)?

**Daved** · 12-11-2006

What IDE do you use?

It shouldn't be about which derived class causes the problem. If the pointer inside the vector is null, then there is no derived class, because the pointer points at nothing.

Did you try vart's suggestion? Which is the first pointer that is bad?

**psychopath** · 12-11-2006

I'm using Visual C++ 2005 Express.

I tried calling assert() after each class is created, although it didn't seem to do anything. In the debugger, otherVector[0] is NULL, meaning it's the bad pointer (I guess). otherVector[0] would be created after calling AddToVector().

**Daved** · 12-11-2006

>> I tried calling assert() after each class is created
What about in that line of code? Look at data in the watch window. If it looks valid, then expand (*data).subclass and look at that. Visual Studio has an excellent debugger, you should be able to find lots of information.

Since otherVector is an object, not a pointer in the code you posted, it would only make sense that the instance of the class that contains it is bad. That is why we are asking about the other things. The crash usually shows up somewhere other than where it is actually being caused. Move down the call stack and dig around looking at each variable to see which variable is the highest level one that is not valid. Only when you find out which pointer is bad should you then figure out why it is bad.

Thread: Copying memory, pointers and the like.

Thread Tools

Search Thread

Display