destructor failure

[elohssa]

on return from main the destructor for this class fails ~25% of the time with inputted command line args always being the same. here is abstraction with only relevant code...

header...

class datFile {
public:
double * VW1, *VW2, *MVAR;
};

imp (there is only 1 method which always gets called and initializes pointers with new)...

void datFile::initDat(std::string p, const int db, int dc, int n) {
filePath=p;
DB=db;
DC=dc;
N=n;
MVAR = new double[db*db];
VW1 = new double[n*(db+1)];
VW2 = new double[n*(dc)];
}

datFile::~datFile() {
delete[] VW1;
delete[] VW2;
delete[] MVAR;
}

My main method calls initDat once for each datFile (really initDat should be a constructor but that is a different matter).

[ne555]

> the destructor for this class fails ~25% of the time
¿what do you mean with `fails' ?

¿did you wrote a copy constructor and assignment operator?
Post the client code.

[elohssa]

"¿what do you mean with `fails' ?"

When "return 0;" is called in main the the datFile object has its destructor invoked but sometimes the program crashes (usually not). If I comment out all the "delete[]s" in the destructor "return 0;" always works.

"¿did you wrote a copy constructor and assignment operator?
Post the client code. "

What is the client code? (sorry for newb question).

[ResidentBiscuit]

Is allocation actually happening? I think deleting non-allocated space would cause a crash. Your initDat() function seems odd, where are DB, filePath, DC, N?

What is the client code?

Assuming he means code that uses this class.

[elohssa]

"Is allocation actually happening?"

Yes, the datFile objects performs its function perfectly until it has to be destroyed. Here is an example of how I use the datFile objects in an abstract version of my main method...

int main(int argc, char** argv) {
datFile FW[2];
FW[0].initDat(string("")+argv[1],atoi(argv[2]),atoi(argv[3]),atoi(argv[4]));
FW[1].initDat(string("")+argv[5],atoi(argv[6]),atoi(argv[7]),atoi(argv[8]));


/*~300 lines of code where the double pointers in datFile are kept untouched allocation wise*/

return 0;
}

"Your initDat() function seems odd, where are DB, filePath, DC, N? "

All are private variables in header of datFile with types int,std::string,int,int.

[ne555]

> 300 lines of code where the double pointers in datFile are kept untouched allocation wise
If you are sure about that, then your princess is in another castle.
You may be accessing out of bounds.

Consider using a debugger, watch when the pointer changes.
http://www.delorie.com/gnu/docs/gdb/gdb_30.html
Try to create a minimal setup that does reproduce your issue.

string("") //¿what is this for?
+argv[1]

[ajh32]

How about making the member pointers in your class Private and add just getters that return a pointer to a constant. Why have ::initDat(...), instead of just initialising in the constructor? Add static count and increment in constructor and decrement in destructor. This should all help you identify the source of the problem.

[elohssa]

"Consider using a debugger, watch when the pointer changes.
http://www.delorie.com/gnu/docs/gdb/gdb_30.html
Try to create a minimal setup that does reproduce your issue."

Problem is the destructor only succeeds when I comment all 3 "delete[]"s out. The pointer MVAR is not referred to once in this particular source code (I have many programs that use datFile class), and even its deallocation fails in the destructor.

string("") //¿what is this for?
+argv[1]

string("") contains a directory but it has my real name in it so i ommited it.

[Disch]

There are only a few ways I can imagine delete[] failing.

1) You are attempting to delete a bad pointer or a pointer that was not allocated with new (seems unlikely judging from your posts).

2) hardware failure (extremely unlikely)

3) You are corrupting memory -- such as accessing memory outside of the allocated arrays. I'd almost be willing to bet the farm that this is your problem.

4) You are shallow copying this class and thus the pointers are getting deleted multiple times. This is also a possibility.



In any case, the actual problem is not in your destructor. It's in the rest of your code that is accessing the array. Here are some ways to approach the problem:

1) Get rid of this manual allocation (new/delete) and use std::vector instead. Not only is it less error prone, safer, and exception safe, but also in debug builds, vectors often expose out of bounds access as they happen, so this will immediately show you where the actual problem is.


2) Use a memory tool like Valgrind or something similar to monitor memory integrity and try to expose the bad memory access that way.


3) Go over all code that accesses these arrays with a very fine toothcomb and make sure you are not stepping out of bounds anywhere (read: you probably are, so if you don't find anything you're probably not looking hard enough).




Obviously I recommend solution #1