segmentation fault on delete object (which belongs to some class under a hierarchy)

J

Joel

I have this bug that quite puzzled me. Basically I am having a
segmentation fault on deleting an object, which belongs to a class
which is the result of multiple inheritance from two other classes.
None of the classes actually allocate memory on the heap. I simplified
my code into one piece to show below. I will really appreciate if
someone can tell me where the problem is. I have spent quite some time
on it and felt a bit lost at this point.

the compiler is g++ (GCC 3.3.2 on Mandrake)

Thank you for your help!

Joel


code
--------------
#include <hash_map.h>

typedef union {
long r1;
double r2;
} rank_t;

struct eqstr {
bool operator()(const char* s1, const char* s2) const {
return strcmp(s1, s2) == 0;
}
};

typedef struct oety {
double p1;
double p2;
oety():p1(1),p2(1) {}
static bool change(oety* s_entry);
} oentry;

typedef struct eety {
rank_t rank;
} eentry;

typedef hash_map<char*, eentry*, hash<char*>, eqstr> EType;

typedef struct oeety : public oentry, public eentry {
oeety() {rank.r2 = 1;}
} oeentry;

int main ( int argc, int argv[] ) {
EType* extraInfo = new EType();

eentry* entry1;
entry1 = new oeentry();
char * s_name = new char[2];
s_name[0] = 'a';
s_name[1] = '\0';
(*extraInfo)[s_name] = entry1;

entry1 = new oeentry();
s_name = new char[2];
s_name[0] = 'b';
s_name[1] = '\0';
(*extraInfo)[s_name] = entry1;

EType::iterator itr = extraInfo->begin();

cout << "point 1" << endl;
delete itr->second; //segmentation fault!!!!!!!!!!!!!!!
cout << "point 2" << endl;

return 0;
}
---------------

result:

point 1
Segmentation fault
 
G

Gianni Mariani

Joel said:
I have this bug that quite puzzled me. Basically I am having a
segmentation fault on deleting an object, which belongs to a class
which is the result of multiple inheritance from two other classes.
None of the classes actually allocate memory on the heap. I simplified
my code into one piece to show below. I will really appreciate if
someone can tell me where the problem is. I have spent quite some time
on it and felt a bit lost at this point.

Your code is deleting a different object than was constructed. This is
the cause of your segfault.


has_map is not standard but is planned to be.

Anyhow - you should try to use the non deprecated header.

#include <ext/hash_map>
#include <iostream>

// gcc requires using namespace __gnu_cxx for hash containers

using namespace __gnu_cxx;
using namespace std;
typedef union {
long r1;
double r2;
} rank_t;

this is easier to read than this whole typedef nonsense.

union rank_t {
long r1;
double r2;
};

struct eqstr {
bool operator()(const char* s1, const char* s2) const {
return strcmp(s1, s2) == 0;
}
};

typedef struct oety {
double p1;
double p2;
oety():p1(1),p2(1) {}
static bool change(oety* s_entry);
} oentry;



typedef struct eety {
rank_t rank;
} eentry;

typedef hash_map<char*, eentry*, hash<char*>, eqstr> EType;

typedef struct oeety : public oentry, public eentry {
oeety() {rank.r2 = 1;}
} oeentry;

int main ( int argc, int argv[] ) {
EType* extraInfo = new EType();

eentry* entry1;
entry1 = new oeentry();

Allocating an oeety object and assigning it to a eety pointer. This
means that the pointer that is stored is not the pointer that was
returned by new.
char * s_name = new char[2];
s_name[0] = 'a';
s_name[1] = '\0';
(*extraInfo)[s_name] = entry1;

entry1 = new oeentry();
s_name = new char[2];
s_name[0] = 'b';
s_name[1] = '\0';
(*extraInfo)[s_name] = entry1;

EType::iterator itr = extraInfo->begin();

cout << "point 1" << endl;
delete itr->second; //segmentation fault!!!!!!!!!!!!!!!

Attempting to delete a pointer that was not returned by new ...

2 solutions - use virtual destructors for the base classes or design it
differently.
 
J

John Harrison

Joel said:
I have this bug that quite puzzled me. Basically I am having a
segmentation fault on deleting an object, which belongs to a class
which is the result of multiple inheritance from two other classes.
None of the classes actually allocate memory on the heap. I simplified
my code into one piece to show below. I will really appreciate if
someone can tell me where the problem is. I have spent quite some time
on it and felt a bit lost at this point.

It's a simple enough problem see below.
the compiler is g++ (GCC 3.3.2 on Mandrake)

Thank you for your help!

Joel


code
--------------
#include <hash_map.h>

typedef union {
long r1;
double r2;
} rank_t;

In C++ we prefer

union rank_t {
long r1;
double r2;
};

You are still programming as if you are writing C. You also might want to
look up 'anonymous unions' in your favourite C++ book.
struct eqstr {
bool operator()(const char* s1, const char* s2) const {
return strcmp(s1, s2) == 0;
}
};

typedef struct oety {
double p1;
double p2;
oety():p1(1),p2(1) {}
static bool change(oety* s_entry);
} oentry;

Again

struct oentry {
double p1;
double p2;
oety():p1(1),p2(1) {}
static bool change(oety* s_entry);
};

And having the struct name different from the typedef name is REALLY WIERD
and therefore a bad thing.
typedef struct eety {
rank_t rank;
} eentry;

Ditto. And this is the place where using an anonymous union would simplify
your code a little. Delete rank_t above and write this

struct eentry {

union {
long r1;
double r2;
};
};

Then you don't have to write

rank.r2 = 1;

you can just write

r2 = 1;
typedef hash_map<char*, eentry*, hash<char*>, eqstr> EType;

typedef struct oeety : public oentry, public eentry {
oeety() {rank.r2 = 1;}
} oeentry;

int main ( int argc, int argv[] ) {
EType* extraInfo = new EType();

eentry* entry1;
entry1 = new oeentry();
char * s_name = new char[2];
s_name[0] = 'a';
s_name[1] = '\0';
(*extraInfo)[s_name] = entry1;

entry1 = new oeentry();
s_name = new char[2];
s_name[0] = 'b';
s_name[1] = '\0';
(*extraInfo)[s_name] = entry1;

EType::iterator itr = extraInfo->begin();

cout << "point 1" << endl;
delete itr->second; //segmentation fault!!!!!!!!!!!!!!!
cout << "point 2" << endl;

return 0;
}

OK here the real point, there is a rule in C++ that you cannot delete an
object through a pointer to its base class unless that base class has a
virtual destructor. Add a virtual destructor to oentry and eentry and you
will be OK. What this means is that any class from which you are considering
deriving another class (now or in the future) should be given a virtual
destructor.

john

BTW is there nay reason not to use std::strings in the code above. Better
than all those char pointers.

john
 
J

Joel

Thanks for all the reply. I guess I did not realize that destructors
behave so much differently than default constructors. I kind of thought
that there is some "default" destructor, which is called automatically
in the base classes (like default constructors, when you do not have any
non-default defined). Apparently this is not the case, which makes sense
too since you can not really have any non-default destructors.

The project came from C and gradually is being added things c++. Quite
some things, including some coding habbits, still looks like c. Thanks
for the criticizements too.
 
J

John Harrison

Joel said:
Thanks for all the reply. I guess I did not realize that destructors
behave so much differently than default constructors. I kind of thought
that there is some "default" destructor, which is called automatically in
the base classes (like default constructors, when you do not have any
non-default defined). Apparently this is not the case, which makes sense
too since you can not really have any non-default destructors.

There is a default destructor, and very useful it is too. But it is not a
virtual destructor. When you delete an object through a pointer to a base
class the base class needs a *virtual* destructor.

john
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,767
Messages
2,569,571
Members
45,045
Latest member
DRCM

Latest Threads

Top