panic alloc -> delete -> kern-exec 3

[Comp_Lex]

Hello,

I have a weird problem. I'm having some memory leakage issues with my software, but I've been able to trace all of them (using hooklogger) until now.
The address seems to point to a globally declared CBase object. The object is initialized with NewL() and it is put in a data-structure.
There seems to be nothing wrong with the data-structure. I had some issues with it, but it is all resolved until I find new issues.
Now, the object contains some data, but the data is deleted in the deconstructor of the object that owns it. You can actually see what happens to it when you set multiple breakpoints in the deconstructor.
The best solution for the panic alloc error is of course to free the memory allocated to the problematic variable, but it in this case it just gives a Kern-Exec 3 error when I do that.

Can someone help me with this, please?

[wizard_hu_]

Since you say it is a global variable, it may happen that you unintentionally delete it multiple times. What happens if you set it to NULL after deletion?

[symbianyucca]

make sure you set all pointers to NULL after deleting them, and make sure you do not delete something that is owned by some other class. These two things usually take away most of the Kern-Exec 3:s.

[Comp_Lex]

I've been working on this and I can't remove the Panic Alloc error. The datastructure that I'm using is a custom made hashtable for my web service app. The hashtable uses a TFixedArray to store the pointers to the objects.
During the deconstruction of the hashtable the functions "DeleteAll" and "Reset" of the array is called. The calls erases all the data, but does this set all stored pointers to NULL?
I am going to look at the "put" and "get" functions of my hashtable to see if they're okay.

[wizard_hu_]

When something is 'custom' it means that you are the only one who is supposed to know what it does.
TFixedArray does not seem to be extremely safe for storing pointers. And its DeleteAll method does not seem to be a bulletproof one, you can check it in e32std.inl. Are you storing pointers of C-classes in it?

[Comp_Lex]

Yes, I'm storing pointers of C-classes in it. I've tried to use RPointerArray, but it gave me trouble. I need some kind of array that I can initialize at the construction of a hashtable, so that I can "Insert" pointers into it without doing something else first in the "put" function.

BTW, this is the troublesome piece of code (It can be traced back to the global pointer):

CMessage::CMessage(const TDesC8& aName) {
	delete iName;
	iName = NULL;
	iName = aName.Alloc(); // #######Panic Alloc#######
}

CMessage::~CMessage() {
	iParts.ResetAndDestroy();
	iParts.Close();
	delete iName;
	iName = NULL;
}

void CMessage::SetName(const TDesC8& aName) {
	delete iName;
	iName = NULL;
	iName = aName.Alloc();
}

[wizard_hu_]

What is in iParts?
Does CMessage inherit from CBase?

[hotcheese]

Are you talking about an alloc panic or a panic on alloc?
An alloc panic indicates you have a memory leak, but you wouldn't get that at the line you have indicated in your code, and your refer to a panic alloc so I presume you must mean there is a panic when you execute a call to alloc() at that line. In which case the only thing that could cause that at the specific line you have indicated is:
a) aName is bad
b) THere is previous heap corruption which manifests when you try another allocation from the heap.

confirming a) would take 5 minutes. In any case, whenever you get a panic, getting the panic number tells you invaluable information as to the cause.

[Comp_Lex]

CMessage inherits from CBase. iParts is a RPointerArray which contains pointers to CPart objects. CPart inherits from CBase as well.
I'm getting a Panic Alloc when I close my application and it has something to do with the allocation of a CMessage. If I check the alloc details on HookLogger then I can see that the address points to an area where a CMessage is being allocated.

[hotcheese]

There's nothing wrong* with the allocating parts relating to iName according to the code shown, so iName in itself cannot be causing a memory leak - unless you are doing something to it (such as a ReAlloc()) not shown in the code. This therefore perhaps implies you need to double check if deleting the containing CMessage object itself properly


* but you don't take into consideration the fact the allocation could fail if there is no memory.

P.S.
There's no point to set a pointer to NULL in a destructor.
There's no need to delete iName in the constructur because it will be guaranteed to be initialized to NULL as CMessage derives from CBase

[Comp_Lex]

I'm going to post a bit more code now:

iMessage = CMessage::NewL(aAttributes[i].Value().DesC());
iMessages->put(aAttributes[i].Value().DesC(), iMessage);

iMessage is a global variable. If I do a "delete" on it in the deconstructor of the class that initiates it, then the result is a Kern-Exec 3 error. The error is caused by the fact that it is deleted in a hashtable datastructure present in the same class.

[symbianyucca]

Have you tried on settings the pointer to NULL, and making sure each place that no other references are used in any place in your project, also make sure each user of the variable will also check against NULL, and only use it if it is non-NULL.

[wizard_hu_]

I'm going to post a bit more code now:

iMessage = CMessage::NewL(aAttributes[i].Value().DesC());
iMessages->put(aAttributes[i].Value().DesC(), iMessage);

Based on what you have shown from CMessage so far, CMessage itself does not seem to cause problems.
Focus on 'put' instead:
- it has a bad name, should be Put
- if it allocates memory, it should be PutL
- if it does not allocate memory (you experiment with some fixed-size hashtable implementation), it is an important question what happens with CMessage-s which may be already there in a given bucket? If you just overwrite them, that would certainly lead to memory leaks.

iMessage is a global variable.

Why? iMessage? Not iMessages?

By the way, if this complete thread is about "aAttributes[i]", are you aware of that RString is already a kind of hash value?
By the way 2, is it sure that you want to use "Value()" in both lines?

[hotcheese]

I'm lost with this posting, hasn't the op identified the problem in the last posting ? i.e.a double deletion:

"If I do a "delete" on it in the deconstructor of the class that initiates it, then the result is a Kern-Exec 3 error. The error is caused by the fact that it is deleted in a hashtable datastructure present in the same class."

Here he is saying it is deleted in the destructor and its also deleted in the hashtable, unless the description is misleading.

[Comp_Lex]

At this time it is only deleted in the hashtable. If I do the extra delete then the program quits with the Kern-Exec 3 message.

I'm going to post a bit more code now:

HashTableElement.h:

#ifndef HASHTABLEELEMENT_H
#define HASHTABLEELEMENT_H

#include <e32base.h>

class CHashTableElement : public CBase {

public:
	
	~CHashTableElement();
	static CHashTableElement* NewL();
	static CHashTableElement* NewLC();
	void SetL(const TDesC8& _key, TAny *_object);
	HBufC8* GetKey();
	TAny* GetObject();
	
protected:
	
	CHashTableElement();
	void ConstructL();
	
private:
	HBufC8* iKey;
	TAny *iObject;
};

#endif /* HASHTABLEELEMENT_H */

HashTableElement.cpp:

/*

#include "HashTableElement.h"

_LIT8(KEmpty, "");

CHashTableElement* CHashTableElement::NewL() {
	CHashTableElement *self = CHashTableElement::NewLC();
	CleanupStack::Pop();
	return self;
}

CHashTableElement* CHashTableElement::NewLC() {
	CHashTableElement *self = new (ELeave) CHashTableElement();
	CleanupStack::PushL(self);
	self->ConstructL();
	return self;
}

void CHashTableElement::ConstructL() {
	iKey = KEmpty().Alloc();
}

CHashTableElement::CHashTableElement() {

}

CHashTableElement::~CHashTableElement() {
	delete iKey;
	iKey = NULL;
	delete iObject;
	iObject = NULL;
}

void CHashTableElement::SetL(const TDesC8& _key, TAny *_object) {
	delete iKey;
	iKey = NULL;
	iKey = _key.Alloc();
	delete iObject;
	iObject = NULL;
	iObject = _object;
}

HBufC8* CHashTableElement::GetKey() {
	return iKey;
}

TAny* CHashTableElement::GetObject() {
	return iObject;
}

HashTable.h:

#ifndef HASHTABLE_H
#define HASHTABLE_H

#include <e32std.h>
#include <e32base.h>
#include <e32cmn.h>
#include <EIKENV.H>
#include "HashTableElement.h"

class CHashTable : public CBase {

public:
	
	~CHashTable();
	static CHashTable* NewL();
	static CHashTable* NewLC();
	void PutL(const TDesC8& key, TAny* object);
	TAny* Get(const TDesC8& key);
	TBool Contains(const TDesC8& key);
	void RemoveElements();
	void Reset();

protected:
	
	CHashTable();
	void ConstructL();

private:
	TFixedArray<CHashTableElement*, 1024> iTable;
	RArray<TBool> iDeactivated;
	TUint Hash(const TDesC8& string);
	HBufC8* iCachedKey;
	TAny* iCachedObject;
	TUint iCachedHash;
	CHashTableElement *iHashElement;
};

#endif /* HASHTABLE_H */

Hashtable PutL function:

void CHashTable::PutL(const TDesC8& key, TAny *object) {
	TUint h;
	if ((iCachedKey) && (*(key.Alloc()) == *iCachedKey)) {
		h = iCachedHash;
	}
	else {
		delete iCachedKey;
		iCachedKey = NULL;
		iCachedKey = key.Alloc();
		h = Hash(key);
		iCachedHash = h;
	}
	iCachedObject = object;
	iHashElement = CHashTableElement::NewL();
	iHashElement->SetL(key, object);
	TInt tableIndex = h % 1024; // compression map
	TBool inserted = EFalse;
	if (iDeactivated[tableIndex]) {
		delete iTable[tableIndex];
		iTable[tableIndex] = NULL;
		iTable[tableIndex] = iHashElement;
		iDeactivated[tableIndex] = EFalse;
		inserted = ETrue;		
	}
	else { // Linear Probing
		TInt i = tableIndex + 1;
		while ((i < 1024) && (!inserted)) {
			if (iDeactivated[i]) {
				delete iTable[i];
				iTable[i] = NULL;
				iTable[i] = iHashElement;
				iDeactivated[i] = EFalse;
				inserted = ETrue;
			}
			else {
				i++;
			}
		}
		i = 0; // end of table reached
		while ((i != tableIndex) && (!inserted)) {
			if (iDeactivated[i]) {
				delete iTable[i];
				iTable[i] = NULL;
				iTable[i] = iHashElement;
				iDeactivated[i] = EFalse;
				inserted = ETrue;
			}
			else {
				i++;
			}
		}	
		if (!inserted) { // table is full
			CEikonEnv::Static()->AlertWin(_L("Error: Hashtable is full"));
		}
	}
}

Hashtable Deconstructor:

CHashTable::~CHashTable() {
	iDeactivated.Reset();
	iDeactivated.Close();
	delete iCachedKey;
	iCachedKey = NULL;
	iTable.DeleteAll(); ######CMessage should be deleted here!######
	iTable.Reset();
}