Massive memory leak

#1 Sounds like you have managed to create some memory usage in the gui side of things..
for it to go up that fast..
I would say it has to do with some rendering..
and you say you have created some gui's ..
I would pass the buck to them.
some crazy bugger has placed some form of memory usage in a Render Loop!!!!


AAIIIEEEE!!!!

Edit:
a Good plan..
would be to use the memory manager.

simply set a hook to moniter allocations after a certian event.

such as a special console command.

then dont do Anything in the game have the debugger break on allocation, and if what you say is true.
there should be allocation's after there shouldn't be and you can track em from there.

#2 Beware the memory query routines, they are not implemented.

According to Torque, it uses 0 bytes of memory.

#3 Actually, there's 2 of them. One returns the actual memory that's been allocated, the other returns 0.

#4 I have been experiencing the same/similar issues regarding players/aiplayers.
Edited aiplayer.cc, no 'New' calls, no new objects, just a few F32 vars added to the header and bot-get-un-stuck code within function:
"bool AIPlayer::getAIMove(Move *movePtr)"
All i have to do is load "trq_tutorial_base" with some path nodes and get a few bots doing a circuit.

I have been under the delusion that creating a memory leak from the scripts was highly unlikely. I think the problem lies there, in the scripts.

Observed:
the memory taken by torque is about 40-50 Megs and fairly stable there, not climbing. The systems cash file though... grows and grows until the system hangs, under 15 min... 4 bots and one player running on one single computer (server == the client)

any ideas? Tell me i just have to clean up my scripts.


---- from commands.cs ---
$botCounter = 0;
function serverCmdAddBot(%client) {
MissionCleanup.add($bots);
%npcName = "Bill_GatesBot" @ $botCounter;
$bots[$botCounter] = AIPlayer::spawnPlayer(%npcName);
MissionCleanup.add($bots[$botCounter]);

$bots[$botCounter].setAttackTargetObject(%client.player);
$botCounter++;
}

function serverCmdAddSidewalkBot(%client) {
MissionCleanup.add($bots); // do i need this again here? suspect
%npcName = "SideWalkBot_" @ $botCounter;
$bots[$botCounter] = AIPlayer::AddPathedBotHere(%npcName, pickRandomSWPath("MissionGroup/Paths/SWpaths"));
$bots[$botCounter].setMoveSpeed(0.2);
MissionCleanup.add($bots[$botCounter]);
$botCounter++;
}
----


Added in aiplayer.cs to the "datablock PlayerData( aiBot : MyPlayer )"
a few vars:
-----
patrolCW = true; // pedestrian direction is Clockwise
speedmax = 0.5; // <= fast sidewalk speed
speedmin = 0.2; // <= side walk speed
WalkCW = true;
------

#5 Just so you know, we got this fixed. And it was Chris's fault (he wasn't de-allocating some OpenGL memory properly that gets allocated with every shapebase)

#6 Found the problem!
----------------
Pumping out lots of data to the console window.
----------------
Windows gets unhappy in a hurry when your console.log gets too big
This will vary on every machine out there but know that you should not be dumping continually to the consol. try to keep it just to the errors in there. ;)

#7 Bryan... is this custom code of yours or is in the release code?

#8 I'm suspect my Linux dedicated server might be suffering a memory leak from the issue Amir mentioned with the console window. The amount of virtual memory just keeps going up and up and up on a regular basis. Will run some further tests soon and report the results.

#9 Scott:
Do you use the database calls?
What customizations on engine you have done?

I'm running Torque (custom build, heavily modded) dedicated under Linux, LOTS of console.log entries for about 24 hours.. At start up the server "eats" about 100 MB, at the end it's about 130-150 MB (but lot's of stuff kept in memory as "dynamic" so it's okay).

#10 @bank:
Actually I am making database calls using one of the ODBC resources. This may have something to do with it, still looking into it...

#11 Scott, I've seen that behaviour.

It's mostly caused by non emptying the results from DB calls, so, all DB results are kept in memory.
See resource comments (search for "the crash when doing disconnect") and read my comments there. It should be self-explanatory.

#12 @bank:
Thanks I read your comments. You know, it's strange. I am calling both clear() and delete() on the results set. At first, memory APPEARS to not be going up. But then, after a certain amount of time sitting there running SELECT queries, the memory suddenly jumps. It jumps at regular intervals and the same amount each time. I know it has something to do with the database results not being cleared --- the bigger my results set, the bigger the memory jump!

Any ideas here?

Note: I am actually using the database resource from Dream Game's MMOKit. It incorporates event-driven database code, which is probably where my problem lies.

#13 Here is what I do:
1. I made the DatabaseConnection object to be SimGroup
2. Made all results to SimObjects and automatically added to the SimGroup
3. Using the code (everywhere in scripts I use %result = $db.Execute(%sql) scheme):

function dbRestart()
{
   $dbnew = new DatabaseConnection(dbNew);
   $dbnew.ConnectDriver($Pref::Server::DB::Driver, $connectionString);
   $dbnew.setName(db);
   $dbold = $db;
   $dbold.setName("dbOld");
   $db = $dbnew;
   $dbold.schedule(4000, "cleanUp");
   $dbold.schedule(5000, "disconnect");
   $dbold.schedule(6000, "delete");
   schedule( $mminutes_10, 0, "dbRestart");
}

being $mminutes_10 = 600000 (10 minutes in milliseconds)
So, every 10 minutes I do the reset of database connection.
Firest, I create a new connection, so scripts starting using the new one.
Scheduled "cleanUp" function that clears all the simobjects on old database connection.
Scheduled disconnect and then delete.
I use schedules just to be sure that some scripts/routine is finished using the old connection/results before it gets cleared.
Try this and check if memory gets jumping every 10 minutes, if so - then you have somewhere a huge leack. If the memory still grows as before - very possible it's not database-related.