Game Development Community

Is this memory leak something to worry about?

by Stefan Lundmark · in Torque Game Engine · 12/08/2005 (10:57 am) · 7 replies

Hello

I've found that there are memory leaks in 1.4 that I haven't seen before. These could be in/out writes, but then again I've seen nothing on the forums, or the changelog, why these would be here now but not before.

There is leaking 3.6kbytes of memory from simDictionary.cc at line 34. The code looks like this and the leak is set in bold:

if(!hashTable)
   {
      [b]hashTable = new SimObject *[DefaultTableSize];[/b]
      hashTableSize = DefaultTableSize;
      hashEntryCount = 0;
      S32 i;
      for(i = 0; i < hashTableSize; i++)
         hashTable[i] = NULL;
   }

It's happening pretty frequently as the code in question seems to be executed alot.
What confuses me is that later on behind the if statement, hashTable is deleted - so there shouldn't be a leak, right?

Anyone who can advice on how to proceed?

*** EDIT ***

Got bored and what did you know! There's three more.

The second one is in consoleObject @ line 358. It is leaking 72 bytes every few seconds, for some reason.
The part which is leaking looks like this:

T::initPersistFields();
      T::consoleInit();
   }

   /// Wrap constructor.
   [b]ConsoleObject* create() const { return new T; }[/b]
};

Are these meant to be here? Maybe they are just writing in and out of memory, like consoleInternal does?
There's a few more of these around, but those two are the most major.

Any word from GG?
NextNext Thread
PrevPrevious Thread
More from Torque Game Engine


Torque Owner Brian Richardson
#1
12/08/2005 (11:45 am)
It's hard to say just with the block you put up there, but it seems like you'd want to clean up like this:

for (U32 i = 0; i < hastTableSize; i++)
  delete hashTable[i];
delete[] hashTable;

This is of couse assumming all of the array items have be innited, otherwise you'd want to check for that in your loop.

Hope that helps
bzztbomb
http://knowhere.net/

Torque Owner Stefan Lundmark
#2
12/08/2005 (11:48 am)
Brian,

Thanks for your reply!

The part I outlined before my edit is infact stock Torque, and I haven't touched it.
This is why I think it's important to know why these are here.

Torque Owner Brian Richardson
#3
12/08/2005 (11:57 am)
Ahh, after looking at simDictionary.cc:

The hashtable array will be freed when the SimDictionary is freed. Also it looks like the objects that are being inserted into the array are not owned by the SimDictionary, so they need to be freed elsewhere.
So whoever created the object that is inserted must deal with freeing it (and removing it from the dictionary as well).

bzztbomb
http://knowhere.net/

Torque Owner Stefan Lundmark
#4
12/08/2005 (1:08 pm)
Gotcha. Then it's just the one in consoleObject, then?

Torque Owner Brian Richardson
#5
12/08/2005 (2:18 pm)
Nah, because it's returning the pointer and which should get freed after the object is done being useful. If there's a leak, it's further up the call stack than here. If this is getting called every few seconds, I'd imagine you've got some objects getting created from a scheduled script function or something, these should be added to MissionCleanup which gets freed after the mission is done.

bzztbomb
Knowhere Studios

Torque Owner Stefan Lundmark
#6
12/08/2005 (3:04 pm)
It's a barebone server only doing TCPObject recieves, it has no mission running or any objects at all created.
Thanks for the help though, very useful as I have no clue on whatever was happening there - all I can see is that the memory-usage starts growing when more users connect.

Torque Owner Gilberto Catarino
Default Studio Name
#7
11/23/2009 (8:57 am)
Did anyone checked if this was really a leak.
Where is that hashTable being destroyed?
Looking at the destructor it only destroys the hashTable not the values inside it.
Is it wise to change the Destructor to this:
SimNameDictionary::~SimNameDictionary()
{
   if(hashTable)
   {   	
	   for (U32 i = 0; i < hashTableSize; i++)  
	   	delete hashTable[i];  				   
   }
   
   delete[] hashTable;
   Mutex::destroyMutex(mutex);
}