472,096 Members | 1,193 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,096 software developers and data experts.

segmentation fault while deleting a pointer in a destructor

Hello,

I have class in which I am allocating space for a double array in the
constructor. I use the double array twice in one of the methods and then
delete that array in the class's destructor.

Now, that delete operation is giving me a segmentation fault. If I move
the allocation and deletion of the pointer within the method where the
pointer is being is used, it works okay ... but then another pointer
gives a segmentation fault in the destructor when that pointer is being
deleted. In all, there a bunch of pointers being used in that one
method. Memory for these is being allocated in the constructor and being
deleted in the destructor (it is not a virtual class).

I am trying to find where is the problem but haven't successful so far.
Before I continue, I have a specific question.

Am I correct in understanding that the pointer allocation using new in a
constructor of a class, then the usage of that pointer in a class member
and subsequent deletion of the pointer in the class destructor is
supposed to go okay?

Thanks.
Aug 4 '08 #1
10 11948
On Aug 3, 8:15 pm, "H.S." <hs.sa...@gmail.comwrote:
Now, that delete operation is giving me a segmentation fault.
Your best bet is to reproduce the problem in the smallest possible
program and to show us. Without seeing what you're doing, we can only
guess. Here is mine:

You haven't defined the copy constructor and/or the assignment
operator, or defined them incorrectly; so the object gets deleted
twice.
Am I correct in understanding that the pointer allocation using new in a
constructor of a class, then the usage of that pointer in a class member
and subsequent deletion of the pointer in the class destructor is
supposed to go okay?
Yes.

Ali
Aug 4 '08 #2
ac******@gmail.com wrote:
On Aug 3, 8:15 pm, "H.S." <hs.sa...@gmail.comwrote:
>Now, that delete operation is giving me a segmentation fault.

Your best bet is to reproduce the problem in the smallest possible
program and to show us. Without seeing what you're doing, we can only
I understand that. But the same program works at other times. So I was
not sure if I would be able to reproduce the problem and thought of
verifying my understanding first.

guess. Here is mine:

You haven't defined the copy constructor and/or the assignment
operator, or defined them incorrectly; so the object gets deleted
twice.
The variable in question are all double arrays and not any custom
objects. For example, the ctor has:
m_dpz = new double [m_n];

m_dpz gets used as a variable to hold a vector in a member function.

The dtor has:
delete [] m_dpz;

Similarly there are other variables (similar type and length).
>
>Am I correct in understanding that the pointer allocation using new in a
constructor of a class, then the usage of that pointer in a class member
and subsequent deletion of the pointer in the class destructor is
supposed to go okay?

Yes.
hmm .. that confirms what I knew. Consequently, a toy example is not
going to show any problems ... I think. With that out of the way, I can
proceed to look for other problems.
Thanks.

Aug 4 '08 #3
On Aug 3, 9:10 pm, "H.S." <hs.sa...@gmail.comwrote:
acehr...@gmail.com wrote:
The variable in question are all double arrays and not any custom
objects. For example, the ctor has:
m_dpz = new double [m_n];

m_dpz gets used as a variable to hold a vector in a member function.
Why not use std::vector?
The dtor has:
delete [] m_dpz;
a toy example is not going to show any problems ...
The toy example will show the problem, by definition. I said "to
reproduce the problem in the smallest possible program". That smallest
possible program is your toy example and by definition it shows your
problem. Once you start adding pieces to it to reproduce, you will
find the culprit.

I wrote this program that causes a "Segmentation fault" on my system:

class C
{
double * m_dpz;

public:

C()
:
m_dpz(new double[1])
{
m_dpz[-2] = 42;
}

~C()
{
delete[] m_dpz;
}
};

int main()
{
C c0;
}

Ali
Aug 4 '08 #4
In article
<8c**********************************@b38g2000prf. googlegroups.com>,
ac******@gmail.com wrote:
[...]
I wrote this program that causes a "Segmentation fault" on my system:
[...]
Or, one that might model the original poster's problem:

class C {
double* p;
public:
C() { p = new double [10]; }
~C() { delete [] p; }
};

int main()
{
C c;
C c2( c );
}
Aug 4 '08 #5
On Aug 4, 5:51 am, acehr...@gmail.com wrote:
On Aug 3, 8:15 pm, "H.S." <hs.sa...@gmail.comwrote:
Now, that delete operation is giving me a segmentation fault.
Your best bet is to reproduce the problem in the smallest
possible program and to show us. Without seeing what you're
doing, we can only guess.
Actually, in such cases, his best bet is some memory management
tool, like Purify or valgrind, which will (usually) signal the
error where it actualy occurs, rather than just leaving
corrupted memory to create a segment violation later.
Here is mine:
You haven't defined the copy constructor and/or the assignment
operator, or defined them incorrectly; so the object gets
deleted twice.
That's also a good guess:-).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Aug 4 '08 #6
blargg wrote:
In article
<8c**********************************@b38g2000prf. googlegroups.com>,
ac******@gmail.com wrote:
>[...]
I wrote this program that causes a "Segmentation fault" on my system:
[...]

Or, one that might model the original poster's problem:

class C {
double* p;
public:
C() { p = new double [10]; }
~C() { delete [] p; }
};

int main()
{
C c;
C c2( c );
}

Thanks, though I feel embarrassed you had to create the example. I
usually create the examples in such situations before posting but here I
wanted to verify something before I thought going down that path.

I have been looking where the problem was and have realized that it is
unlikely to occur in the class where the segmentation fault is being given.

It appears that the culprit might be in the arguments being passed to
the class.

Regards,
->HS
Aug 4 '08 #7
James Kanze wrote:
On Aug 4, 5:51 am, acehr...@gmail.com wrote:
>On Aug 3, 8:15 pm, "H.S." <hs.sa...@gmail.comwrote:
>>Now, that delete operation is giving me a segmentation fault.
>Your best bet is to reproduce the problem in the smallest
possible program and to show us. Without seeing what you're
doing, we can only guess.

Actually, in such cases, his best bet is some memory management
tool, like Purify or valgrind, which will (usually) signal the
Yup, I agree. I thought of doing so last night but then got caught up in
a different minor problem I discovered. I am going to try valgrind now
and see what it comes up with.
error where it actualy occurs, rather than just leaving
corrupted memory to create a segment violation later.
>Here is mine:
>You haven't defined the copy constructor and/or the assignment
operator, or defined them incorrectly; so the object gets
deleted twice.

That's also a good guess:-).

I checked this and this doesn't appear to be case here.

regards,
->HS
Aug 4 '08 #8
ac******@gmail.com wrote:
On Aug 3, 9:10 pm, "H.S." <hs.sa...@gmail.comwrote:
>acehr...@gmail.com wrote:
>The variable in question are all double arrays and not any custom
objects. For example, the ctor has:
m_dpz = new double [m_n];

m_dpz gets used as a variable to hold a vector in a member function.

Why not use std::vector?
In this particular case I have to provide a pointer to an external
library function. At all other places in my own code I am using STL
vectors and deques though.

Thanks for your work in creating the example below.
->HS
Aug 4 '08 #9
H.S. wrote:
James Kanze wrote:
>On Aug 4, 5:51 am, acehr...@gmail.com wrote:
>>On Aug 3, 8:15 pm, "H.S." <hs.sa...@gmail.comwrote:
Now, that delete operation is giving me a segmentation fault.
Your best bet is to reproduce the problem in the smallest
possible program and to show us. Without seeing what you're
doing, we can only guess.
Actually, in such cases, his best bet is some memory management
tool, like Purify or valgrind, which will (usually) signal the

Yup, I agree. I thought of doing so last night but then got caught up in
a different minor problem I discovered. I am going to try valgrind now
and see what it comes up with.
Valgrind pin pointed the problem. There was memory corruption being
caused by the arguments passed to the class in question. The class
itself was performing okay, as I had initially assumed, but wanted to
verify the destructor/constructor behavior.

Thanks everyone.
->HS

Aug 4 '08 #10
In message <g7**********@aioe.org>, H.S. <hs**************@gmail.com>
writes
>ac******@gmail.com wrote:
>On Aug 3, 9:10 pm, "H.S." <hs.sa...@gmail.comwrote:
>>acehr...@gmail.com wrote:
>>The variable in question are all double arrays and not any custom
objects. For example, the ctor has:
m_dpz = new double [m_n];

m_dpz gets used as a variable to hold a vector in a member function.

Why not use std::vector?

In this particular case I have to provide a pointer to an external
library function.
So use a vector internally, to get the benefits of its memory
management, and pass &v[0] to the external library.
>At all other places in my own code I am using STL
vectors and deques though.

Thanks for your work in creating the example below.
->HS

--
Richard Herring
Aug 13 '08 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by deancoo | last post: by
27 posts views Thread by Paminu | last post: by
2 posts views Thread by pragtideep | last post: by
9 posts views Thread by aamircheema | last post: by
3 posts views Thread by jr.freester | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.