segmentation again ...

[fluppe]

Hi,
i guess it's a simple question ... when my application terminates, i don't need to call the destructor for my object explicitly, or ?

That's all... i'm getting unsure about that, because of a "segmentation fault" that is thrown when my "main"-fcn terminates ... and i just can't fix it ...
So, maybe ...

Thanks

[mutexe]

no you dont need to.

[Catfish4]

That's all... i'm getting unsure about that, because of a "segmentation fault" that is thrown when my "main"-fcn terminates ... and i just can't fix it ...

A segmentation fault usually occurs when you access memory that you shouldn't. So perhaps you have a bad pointer in your program.

Example:
http://coliru.stacked-crooked.com/a/d231c845c5ba5a69

[fluppe]

Of course I have, but i don't know where ... it can only be memory allocated by my constructor that is not properly "freed" or memory, that is freed without being allocated, i'm sure.
All methods can access my objects dynamic fields perfectly, .... without exceptions.
but when "main" terminates, the exception is thrown (checked it all in the debugger).
So, it must be the "destructor" that is wrong, or ?

And now i wonder if it it is even called ...

[Catfish4]

We can keep guessing what the problem is all day long, but if you want more than that you must post your code.

[fluppe]

Oh well, actually my question was answered yet ... by mutexe ...

my code is:

obj::obj(int len, double data){

int l=0;

mat = (double**)malloc(sizeof(double)*len);
for(l=0; l< len; l++){
      mat[l] = (double*)malloc(len*sizeof(double));
}
}

and for the destruktor:

obj::~obj(){

int l;
for(l=0; l<len; l++){

free(mat[l]);
}
free(mat);
}

.... roughly ... but it is what happens ...with more complex Objects at last.

[AbstractionAnon]

it can only be memory allocated by my constructor that is not properly "freed"

No. Not properly freeing memory will result in a memory leak, but will not cause a segmentation fault.

Segmentation faults occur trying to read or write memory you don't own.

The primary causes of segmentation faults are bad pointers or an index out of range.

Where are you in the code when you get the segmentation fault?

edit: You stated the segmentation fault occurs in the destructor. This indicates the heap has been corrupted. This is probably due to indexing outside of the limits of the array before the destructor is called.

[fluppe]

So it might be that i have some index out of range before the destructor is called, but the segmentation fault occurs afterwards ?? I thought it would always give an exception right away ... without queueing.

That's new to me.
I also didn't know if unfreed memory can never lead to such an exception.

[Catfish4]

In your constructor you mistakenly allocate a dynamic array of double instead of pointer to double, at the beginning.

obj::obj(int len, double data)
{
    int l=0;

    //mat = (double**)malloc(sizeof(double)*len);
    mat = (double**)malloc(sizeof(double *) * len);

    for(l=0; l< len; l++)
    {
        mat[l] = (double*)malloc(len*sizeof(double));
    }
}

[AbstractionAnon]

So it might be that i have some index out of range before the destructor is called, but the segmentation fault occurs afterwards ?? I thought it would always give an exception right away ... without queueing.

Depends on the nature of the violation. If your're running a checked (debug) build, then yes, the run time will normally catch a simple index out of bounds. However, if it's an invalid pointer that's trashing random memory, then no, a checked build won't catch that at time of reference as long as the pointer is inbounds.

I also didn't know if unfreed memory can never lead to such an exception.

Depends on how it's allocated. If you call malloc and never call free, as I stated that will case a memory leak, but won't cause a exception on termination. If you allocate an object (obj) globally or on the stack (not dynamically), obj's destructor WILL be called upon exiting main. Anything at termination that causes an object to be deleted, or memory to be freed requires that the heap is intact. If it's not, you can get a variety of error, most common of which is segmentation fault.

catfish4 definately spotted an error. That may or may not be your only issue. One way to catch this type of error is to scatter calls to heap_check in your code. Name of the function will vary depending on your specific environment, but most environments have something similar. For Visual Studio:
http://msdn.microsoft.com/en-us/library/z8h19c37(v=vs.90).aspx

[fluppe]

Hi and thanks a lot so far.
@catfish4 : I'm gonna check that in my code ... i didn't use "copypaste", so i'm not sure, if it's not just typed false in here.

I gonna see this as solved. The answers have been helpful enough and i will have to check my program carefully now, to either find the answer or some new, more detailed questions, i guess.

Thank you