I'm getting an error - heap corruption, can't figure out why.
My base :
h:
class Base
{
public :
Base(char* baseName, char* cityName);
virtual ~Base();
list<Vehicle*>::const_iterator GetEndList();
void PrintAllVehicles(ofstream &ResultFile) const;
char* GetBaseName() const;
char* GetLocation() const;
void InsertNewVehicleToBase(Vehicle* newVehicle);
list<Vehicle*>::const_iterator FindVehicle(char* id);
void RemoveVehicle (list<Vehicle*>::const_iterator beg);
private:
char* m_name;
char* m_location;
list<Vehicle*> m_baseVehicles;
};
cpp :
Base::Base(char* baseName, char* cityName)
{
m_name = new char [strlen(baseName)+1];
strcpy(m_name, baseName);
m_location = new char [strlen(cityName)+1];
strcpy(m_location, cityName);
}
Base::~Base()
{
delete [] m_name;
delete [] m_location;
//m_baseVehicles.clear();
}
army destructor :
Army::~Army()
{
list<Base*>::iterator baseIter = m_basesList.begin();
for (baseIter ; baseIter != m_basesList.end() ; ++baseIter)
delete (*baseIter);
m_basesList.clear();
}
What am I doing wrong?
There's nothing obviously wrong with the code you've shown, so chances are that the error is in code you haven't shown.
The most immediately suspicious thing to me is that the Base class owns two pointers and does not have a copy constructor or assignment operator defined. This means that should you ever copy a Base object, you will end up with two Base objects pointing to the same data, and when they destruct, they will delete it twice, causing heap corruption.
The Army class may also have this problem as well (since it owns several Base pointers), but you don't show the definition of the class, so it's not obvious whether it has a copy constructor and assignment operator or not.
Finally, you haven't shown where the Base objects are being allocated. Is it possible that they are being passed into an Army object and also deleted somewhere outside the Army object? Or perhaps the Base* contained by the Army object are referring to objects on the stack that should not be deleted?
Visible problems with this code:
use of char* not std::string requires manual memory management
Use of
raw pointers in STL containers
overcomplicates cleanup code
use of CRT for string manipulation is
a C++ 'code smell'
Nothing wrong with the piece of code given.
But with this kind of code, there is a high possiblity of mutiple deletion, I mean deletin a memory block twice which leads to heap corruption.
You didn't post the part of the code that has the problem, because all that looks pretty normal. However, it's got a lot of const-correctness problems:
Base(char* baseName, char* cityName);
Strings should be passed as const char* unless they are being modified.
virtual ~Base();
No idea if this needs to be virtual; can't see what its subclasses are.
list<Vehicle*>::const_iterator GetEndList();
Should be a const method, since it's a const_iterator: list<Vehicle*>::const_iterator GetEndList() const;
char* GetBaseName() const;
char* GetLocation() const;
These should return const char*, since your code is not set up to handle the name and location being changed.
list<Vehicle*>::const_iterator FindVehicle(char* id);
Again, should be a const method: list<Vehicle*>::const_iterator FindVehicle(char* id) const;
Base::~Base()
{
delete [] m_name;
delete [] m_location;
//m_baseVehicles.clear();
}
You don't need m_baseVehicles.clear(); because it happens anyway right after the destructor. However, you need to delete the vehicles if they aren't referenced elsewhere, or you'll get a leak.
army distructor :
"destructor". And where is the rest of Army?
Army::~Army()
{
list<Base*>::iterator baseIter = m_basesList.begin();
for (baseIter ; baseIter != m_basesList.end() ; ++baseIter)
delete (*baseIter);
m_basesList.clear();
}
Again, you don't need m_basesList.clear();.
I don't see any problem. Just as Matt Kane said, how does it get populated?
Heap corruptions come from copying more data into an allocated heap cell than the memory allocated to the cell. The beginning and end of heap cells contain data than when overwritten will be reported as a heap corruption.
You have not posted all the code and I cannot see a problem in the code you have posted but I would advise using a memory tool like Valgrind to help you diagnose the problem.
Related
I am not going to past the whole source because it is 1000+ rows, but I have specially constructed a similar case about the matter I am interested in. Pay attention to this source code:
#include <iostream>
using namespace std;
class Person
{
public:
Person();
Person(char*);
~Person();
Person& operator=(const Person&);
friend Person& example(const Person&);
void print() const;
private:
char* name;
};
Person::Person()
{
name = new char[12];
name = "Temp";
}
Person::~Person()
{
delete[] name;
}
Person::Person(char* _name)
{
name = new char[strlen(_name)+1];
strcpy_s(name,strlen(_name)+1,_name);
}
Person& example()
{
char* TestName = new char[11];
TestName = "ShouldStay";
Person B(TestName);
return B;
}
void Person::print() const
{
cout << name;
}
int main()
{
example();
return 0;
}
In this case the example() function will return:
example returned {name=0x007cad88 "îþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþîþ... } Person &
So obviously the destructor is called on the return command and delete the memory in the heap (so I am not able to do anything further with the pointer - it is pointing to already freed memory - no data).
My question is - How to avoid such behavior? What is the most elegant way to avoid such issue?
Thank you in advance!
Use string rather than char[] to avoid having to use new.
Return Person rather than Person&, as locally-scoped classes
are destroyed after they leave scope. Although this will cause a
copy to happen depending on compiler settings. This depends of course upon providing a proper copy constructor.
To guarantee avoiding a copy, change the signature of example to:
void example(Person& person)
And fill in the fields of the inputted person inside the function. The scope of that Person will be bound to the calling scope (or wherever else you constructed it). This method has drawbacks though such as you cannot chain the results together.
Your code contains many logical errors:
Person::Person()
{
name = new char[12];
name = "Temp";
}
In the above function you allocate a char array of 12 elements, then you simply forget about it and instead make name pointing to a string literal.
Person::~Person()
{
delete[] name;
}
whoopps. In case Person was build from a default constructor this would delete a string literal. A no-no in C++.
Person::Person(char* _name)
{
name = new char[strlen(_name)+1];
strcpy_s(name,strlen(_name)+1,_name);
}
Not 100% sure what strcpy_s is, but the code in this case allocates an array and seems to copy the string into the array. This seems ok (but just strcpy(name, _name); would have been better for many reasons).
Person& example()
{
char* TestName = new char[11];
TestName = "ShouldStay";
Person B(TestName);
return B;
}
This code is seriously broken. First of all it's returning by reference a temporary object. A Very Very Bad Idea. It's also allocating an array, and once again just forgetting about it and using a string literal instead.
The most elegant way (actually the ONLY way in my opinion) to get your code working is to first understand how the basics of C++ work. You should start first by reading a good C++ book from cover to cover, and only then you should start coding in C++.
Your 1000 lines of source code are most probably just rubbish. I'm not saying you're dumb, just that you don't know the basics of C++. Take care of them first by reading, not experimenting with a compiler.
You cannot learn C++ by experimenting for two reasons:
It's a complicate and sometimes even just downright illogical language because of its history. Guessing is almost always a bad move. No matter how smart you are there's no way you can guess correctly what a committee decided.
When you make a mistake there are no runtime error angels to tell you so. Quite often it happens that apparently the program works anyway... until it's run by your teacher, boss or spouse. Guessing C++ rules by writing code and observing what happens is nonsense.
Person& example()
{
char* TestName = new char[11];
TestName = "ShouldStay";
Person B(TestName);
return B;
}
The above creates an instance of Person on the stack, scoped to the function. So when the function returns, the destructor for Person is called and a reference to the destroyed object (on the stack) is returned.
In addition you should either consider returning a copy of Person, or you need to use the new operator to create an instance of person on the heap and return a pointer to that.
I write an interpreter, in which each keyword, syntax notation or operator has the base class of Token.
class Token {
private:
static std::vector<Token *> registered;
size_t id;
std::string name;
std::string symbol;
public:
Token(const std::string& Name, const std::string& Symbol);
Token::~Token();
Token(const Token& rhs) = delete;
Token& operator =(const Token& rhs) = delete;
/* ... */
static void DeleteRegistered();
};
The constructor:
Token::Token(const std::string& Name, const std::string& Symbol)
: name(Name), symbol(Symbol) {
Token::registered.push_back(this);
this->id = Token::registered.size();
}
The destructor:
Token::~Token() {
// Removes 'this' from Token::registered
Token::registered.erase(std::remove(Token::registered.begin(), Token::registered.end(), this), Token::registered.end());
}
DeleteRegistered:
void Token::DeleteRegistered() {
for (size_t i = 0; i < Token::registered.size(); ++i) {
delete Token::registered[i];
}
}
In my code, many different classes store containers of pointers to sub-classes which eventually derive from Token.
In order to avoid deleting objects twice or more, I store references to all of the allocated instances, and have a static method which will delete them all.
The method DeleteRegistered is called after all operations are done executing.
Now, to my problem:
When I call Token::DeleteRegistered (which happens a few lines before the program exits, it fails and in debug shows the following:
File: f:\dd\vctools\crt\crtw32\misc\dbgdel.cpp
Line: 52
Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
Since all of the Token instances don't really have a defined scope, I came up with this design, which to me currently seems OK.
What can cause this error?
EDIT:
The destructor was a late addition of mine, commenting it out still shows the error above. The delete fails to delete even the first item in the container.
2ND EDIT:
An example of how I use Token:
this->parser.Operators.Add(new RefBinaryOperator(
"Assignment", "=", 14, RefBinaryOperator::Assign
));
Note: RefBinaryOperator is a sub-class of Token (Not direct), which eventually calls Token's constructor.
So for instance, I pull pointers to Tokens from the Operators container, and assign them to other structures. When everything is done, I call DeleteRegistered.
FINAL EDIT:
I got it working by declaring the Token destructor as virtual:
Does delete work with pointers to base class?
What is happening is that in Token::~Token() you are calling erase from the registered vector which is invalidating the indices used in the for loop where you noticed the problem. You need to remember that once you call erase on that vector, the for loop indices need to be adjusted properly. If you keep your current destructor the following could work in DeleteRegistered:
void DeleteRegistered() {
while(!Token::registered.empty())
delete *Token::registered.begin();
}
Also, since you have many classes which extend off of Token, ~Token() should become virtual so that the destruction for the base class will be properly handled.
void Token::DeleteRegistered() {
for (size_t i = 0; i < Token::registered.size(); ++i) {
delete Token::registered[i];
}
}
The above will not do what you want. It's going to remove the first (0th) element from registered. What was the second element now becomes the first (0th element), but now i will be 1. Your loop will remove only every other element from Token::registered. It leaks.
One way to handle this: Keep removing either the first or last element while the vector is not empty. I'd suggest deleting the last element because that's more consistent with how vectors work. Deleting the first element until the vector is empty involves rebuilding the vector each step.
void Token::DeleteRegistered() {
while (! Token::registered.empty()) {
delete Token::registered.back();
}
}
So i have the following class
class Community
{
private:
char* Name;
char foundationDate[11];
Person* founder;
int maxMembersCount;
int membersCount;
Person* members;
static int communitiesCount;
.....
and i want to implement a copy constructor :
Community::Community(const Community& other)
{
this->Name = new char[strlen(other.Name)+1];
strcpy(this->Name,other.Name);
strcpy(this->foundationDate,other.foundationDate);
this->founder = other.founder;
this->maxMembersCount = other.maxMembersCount;
this->membersCount = other.membersCount;
this->members = new Person[this->maxMembersCount];
this->members = other.members;
communitiesCount++;
}
but this code crashes whenever i say Community A=B;
so for me this code seems legit, but when i start debugging there is the message: this-> "unable to read memory". Please help me if you need more code example please let me know.
Community::Community(const char* name , char foundDate[],Person* founder,int maxMembers) {
this->Name = new char[strlen(name)+1];
strcpy(this->Name,name);
strcpy(this->foundationDate,foundDate);
this->founder = new Person(founder->getName(),founder->getEGN(),founder->getAddress());
this->maxMembersCount = maxMembers;
this->membersCount = 2;
this->members = new Person[this->maxMembersCount];
communitiesCount++;
}
this is the main constructor of the class which works just fine....
There are multiple problems here, any of whichi could be part or all of the problem.
If Name or foundationDate is not null-terminated on the right-hand side, it will run off and copy bad memory.
If founder or members are owned by the object, you will either leak memory if you don't delete them in the destructor, or cause a whole variety of memory-related problems when you shallow-copy and then delete twice, etc.
To fix this, just make your Name and foundationDate std::string, and then make founder and members be owned by value rather than by pointer. If you absolutely have to allocate them on the heap use a smart pointer such as shared_ptr to hold it instead of a bug-prone raw pointer.
First of all, check that other.Name is filled with a pointer to a null-terminated string, that other.foundationDate contains a null-terminated string. That is, you pass good pointers to strlen and strcpy.
If that's true, check that B in the assignment is accessible altogether.
If that's true too, printf everything. And debug where exactly the exception occurs. Or post whole code that is compilable and which reproduces the error.
Also note that here:
this->members = new Person[this->maxMembersCount];
this->members = other.members;
the first assignment does nothing (leaks memory, in fact) while the second double deletes your memory upon object destruction (if you properly delete[] members).
At my university, there is a practical programming test in C++ - and I'm stuck with an example where I am unsure about wheter or not the task in question is even valid and possible to complete correctly.
The (simple) tasks:
Complete the destructor of Person, so that the allocated name is freed again
In the main function, replace //??? with the statement required to free the previously allocated memory
At first, the tasks seemed trivial for me: For the destructor, simply write delete[] name and in the main function, use delete[] friends. Presumably, that is also what the author of this example meant us to do.
However:
There seems to be a flaw in this code example, which causes memory leaks as well as destructors to be called more than once.
The person class has no assignment operator =, meaning that as the existing Person objects such as maria are assigned to slots in the friends array in the main function, the internal allocated names are not copied. So two objects now share the same internal char* pointer! Moreover, the pointer to the name of the Person previously residing in the said array slot is permanentely lost, leading to an unavoidable memory leak.
As delete[] friends; is called - the objects in the array are destroyed - leading to their destructors being called and freeing their name members. When the program ends, though, the local Person objects in the scope of main are destructed - which of course have their name members still pointing to memory which was already freed before.
The actual question:
Is this test example flawed, or am I missing something?
Can the issues listed above be fixed if sticking fully to carrying out the given tasks (altering just the implementation of the destructor, and inserting new code at the commented part in the main function)?
..
#include <iostream>
using namespace std;
int strlen(const char *str) {
if (str==0) return 0;
int i=0;
for (; str[i]; ++i);
return i;
}
void strcpy(const char *src, char *dest) {
if (src==0 || dest==0) return;
int i=0;
for (; src[i]; ++i) dest[i]=src[i];
dest[i]=’\0’;
}
class Person {
char *name;
public:
Person(const char *str = "Susi") {
name = new char[strlen(str)+1];
strcpy(str,name);
}
Person(const Person &p) {
name = new char[strlen(p.name)+1];
strcpy(p.name,name);
}
~Person() {
//...
}
void change() {
name[4]='e';
}
ostream &print(ostream &o) const {
o<<name;
return o;
}
};
int main() {
Person maria("Maria"), peter("Peter"), franz("Franz"), luisa("Luisa");
Person mary(maria);
Person luise;
Person p(luise);
Person *friends= new Person[7];
friends[0]=maria;
friends[1]=peter;
friends[2]=franz;
friends[3]=luisa;
friends[4]=mary;
friends[5]=luise;
friends[6]=p;
friends[5]=luisa;
friends[3].change();
friends[4].change();
for (int i=0; i<7; ++i) {
friends[i].print(cout);
cout<<endl;
}
//???
return 0;
}
You are absolutely right. You can fix it by only making changes at the indicated positions, however they are going to be rather extreme:
Replace the //... inside the destructor with:
delete[] name;
}
Person& operator=(const Person& other)
{
if (this != &other) {
delete[] name; // not completely exception-safe!
name = new char[strlen(other.name)+1];
strcpy(other.name,name);
}
return *this;
Another serious problem is redefining a standard function (strcpy) with a new definition that reorders the arguments.
(See also: SQL injection attacks, which also cause existing pairs of syntax elements, frequently quotes and parentheses, to be re-paired with inserted syntax elements)
Yes, the test example is flawed, possibly it was done consciously. Class Person definitely need assignment operator, remember the Rule Of Three.
No, it's not possible. Default compiler-generated assignment operator will leak memory allocated by objects in friends array and double-delete memory allocated by auto Person objects.
For every new there should be a delete[].
I have a class that holds a few vectors, I'm not sure which method is the best but when the I call the destructor they should be deleted from memory.
HEADER:
class Test
{
public:
Test();
~Test();
void AddString(char* text);
void AddString(string text);
private:
char * StringToCharPointer(string value);
vector<char*> *pVector;
}
CPP File:
Test::Test()
{
};
Test::~Test()
{
vector<char*>::iterator i;
for ( i = pVector->begin() ; i < pVector->end(); i++ )
{
delete * i;
}
delete pVector;
};
char * Test::StringToCharPointer(string value)
{
char *pChar = new char[value.length()];
strcpy(pChar, value.c_str());
return pChar;
};
Test::AddString(char* text)
{
pVector->push_back(text);
};
Test::AddString(string text)
{
pVector->push_back(StringToCharPointer(text));
};
so here's pretty much all the methods that I use, but what's wrong?
Firstly, i is an iterator on the vector, it is not the pointer stored in the vector. *i is the pointer stored in the vector, so if you're going to delete anything it should be that.
Secondly, delete *i is only valid if the object pointed to by *i was allocated with new. Not new[], not malloc, and it doesn't point to a string literal. Since you don't say how your data was allocated, it is not possible for us to say whether or not you are freeing it correctly.
It seems likely that you should use a std::vector<std::string>.
Update for updated question:
HEADER:
class Test
{
public:
Test();
~Test();
void AddString(const string &text);
private:
vector<string> mVector;
};
CPP file:
Test::Test()
{
};
Test::~Test()
{
};
void Test::AddString(const string &text)
{
mVector.push_back(text);
};
Your destruction code looks fine (although I guess you meant delete *i; in the second snippet, since otherwise, ti wouldn't have even compiled.
However, the errors you are getting indicate you put bad things in your vectors. The only char*s that can be inserted in the vector with such destruction code are the ones returned by new char. Especially, you must not insert literals ("abc") or strings that are made as parts of other strings (strtok(NULL, ":"), strchr(str, ':') into it.
This is one obvious problem: char *pChar = new char[value.length()];. You are doing new[] but doing delete in destructor which invoked undefined behavior. You should use delete[] to delete those pointers. But using delete[] might give problems for Test::AddString(char* text) method as you can not be sure how memory for text is allocated i.e. using new or new[] or malloc. The simplest way is to use std::vector<std::string> as suggested by Steve Jossep.
It seems likely that you should use a std::vector<std::string>, to shorten the wise words of Steve Jessop.
To elaborate a little more: you say you want "to make the memory allocation smaller", but sounds like you're at the wrong path if you don't know pointers, and correct me if I'm wrong in guessing premature optimization (usually the case with inexperienced developers in this type of question).