Texture leak on exit
by Bloodknight · in Torque Game Engine Advanced · 06/06/2009 (4:43 am) · 9 replies
I'm having an torrid time trying to figure this one out as nothing seesm to point to anything useful, if anybody has any tips on how to track this that would be great
my callstack
my console log
Cur. D3DDevice ref count=2
GFXTextureObject Usage Report - 1 active TOs
---------------------------------------------------------------
Addr Dim. GFXTextureProfile ProfilerPath DebugDescription
a68e030 ( 256, 256) GFXFontTextureProfile na Read Font Sheet
----- dump complete -------------------------------------------
my callstack
ntdll.dll!77250004() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] > LandofThule_DEBUG.exe!Platform::debugBreak() Line 16 C++ LandofThule_DEBUG.exe!GFXTextureObject::dumpActiveTOs() Line 39 C++ LandofThule_DEBUG.exe!GFXDevice::~GFXDevice() Line 257 C++ LandofThule_DEBUG.exe!GFXD3D9Device::~GFXD3D9Device() Line 120 + 0x57 bytes C++ LandofThule_DEBUG.exe!GFXPCD3D9Device::~GFXPCD3D9Device() + 0x14 bytes C++ LandofThule_DEBUG.exe!GFXPCD3D9Device::`scalar deleting destructor'() + 0x14 bytes C++ LandofThule_DEBUG.exe!GFXDevice::destroy() Line 194 + 0x21 bytes C++ LandofThule_DEBUG.exe!Platform::shutdown() Line 264 C++ LandofThule_DEBUG.exe!StandardMainLoop::shutdown() Line 212 C++ LandofThule_DEBUG.exe!TorqueMain(int argc=1, const char * * argv=0x03765230) Line 41 C++ LandofThule_DEBUG.exe!run(int argc=1, const char * * argv=0x03765230) Line 279 + 0xd bytes C++ LandofThule_DEBUG.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * __formal=0x00000000, char * lpszCmdLine=0x002e301d, HINSTANCE__ * __formal=0x00000000) Line 343 + 0x17 bytes C++ LandofThule_DEBUG.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C LandofThule_DEBUG.exe!WinMainCRTStartup() Line 182 C kernel32.dll!755ce4a5() ntdll.dll!772bcfed() ntdll.dll!772bd1ff()
my console log
Cur. D3DDevice ref count=2
GFXTextureObject Usage Report - 1 active TOs
---------------------------------------------------------------
Addr Dim. GFXTextureProfile ProfilerPath DebugDescription
a68e030 ( 256, 256) GFXFontTextureProfile na Read Font Sheet
----- dump complete -------------------------------------------
About the author
#2
Looks like it's just a texture leak.
06/07/2009 (9:20 am)
What's the exception, or what does the assertion message say?Looks like it's just a texture leak.
#3
ive posted the relevent log + the callstack.
The search turned up nothing of value and this is triggering about 70% of the time on exit
06/07/2009 (10:08 am)
the assert simply says "There is a texture object leak, check the log for more details."ive posted the relevent log + the callstack.
The search turned up nothing of value and this is triggering about 70% of the time on exit
#4
Are you running 1.7 by any chance?
06/07/2009 (2:20 pm)
It's because you're running a debug build, which is more verbose than a release build. I've seen this alot back in 1.7, but not in our 1.8.1 builds.Are you running 1.7 by any chance?
#5
For now ive just commented out the assert i know its not the done thing but i cant find the source lol
06/07/2009 (7:05 pm)
actually no, ive only seen this issue since i upgraded my project to 1.8.1, maybe its something ive ported across?For now ive just commented out the assert i know its not the done thing but i cant find the source lol
#6
Here's the diffs straight from the Subversion history:
06/08/2009 (4:53 am)
Remembered fixing this a while back for Torque 3D. The problem was that SimGroup wasn't overriding clear(), causing its SimObjects to become orphanes. The read font sheet leak shows with the inspector editor code.Here's the diffs straight from the Subversion history:
Index: simSet.cpp
===================================================================
--- simSet.cpp (revision 17554)
+++ simSet.cpp (revision 17555)
@@ -275,6 +275,12 @@
void SimGroup::removeObject(SimObject* obj)
{
lock();
+ removeObjectNoLock( obj );
+ unlock();
+}
+
+void SimGroup::removeObjectNoLock(SimObject* obj)
+{
if (obj->mGroup == this)
{
obj->onGroupRemove();
@@ -282,7 +288,6 @@
objectList.remove(obj);
obj->mGroup = 0;
}
- unlock();
}
//-----------------------------------------------------------------------------
@@ -310,6 +315,20 @@
//-----------------------------------------------------------------------------
+void SimGroup::clear()
+{
+ lock();
+ while( size() > 0 )
+ {
+ SimObject* object = objectList.last();
+ removeObjectNoLock( object );
+ object->deleteObject();
+ }
+ unlock();
+}
+
+//-----------------------------------------------------------------------------
+
SimObject *SimGroup::findObject(const char *namePath)
{
// find the end of the object nameIndex: simSet.h
===================================================================
--- simSet.h (revision 17554)
+++ simSet.h (revision 17555)
@@ -104,7 +104,7 @@
virtual bool reOrder( SimObject *obj, SimObject *target=0 );
SimObject* at(S32 index) const { return objectList.at(index); }
- void clear();
+ virtual void clear();
/// @}
virtual void onRemove();
@@ -235,6 +235,8 @@
typedef SimSet Parent;
SimNameDictionary nameDictionary;
+ void removeObjectNoLock(SimObject*);
+
public:
~SimGroup();
@@ -247,6 +249,7 @@
virtual void removeObject(SimObject*);
virtual void onRemove();
+ virtual void clear();
/// Find an object in the group.
virtual SimObject* findObject(const char* name);Index: dynamicGroup.cpp
===================================================================
--- dynamicGroup.cpp (revision 17554)
+++ dynamicGroup.cpp (revision 17555)
@@ -119,8 +119,6 @@
void GuiInspectorDynamicGroup::clearFields()
{
- // JCF: wow, looks like this is leaking memory bad.
-
// save mAddCtrl
Sim::getGuiGroup()->addObject(mAddCtrl);
// delete everything else
#8
The problem itself is in SimGroup and thus pertains to all of TGEA. If a SimGroup gets clear()'ed, it will leak its SimObjects without the above change.
I don't remember noticing it anywhere else, though. It was just that the inspector code was leaking lots of SimObjects and Torque 3D's leak checker barfed on program exit.
06/08/2009 (5:32 am)
The problem itself is in SimGroup and thus pertains to all of TGEA. If a SimGroup gets clear()'ed, it will leak its SimObjects without the above change.
I don't remember noticing it anywhere else, though. It was just that the inspector code was leaking lots of SimObjects and Torque 3D's leak checker barfed on program exit.
#9
06/08/2009 (6:33 am)
works a treat, Thank you :)
Torque 3D Owner Bloodknight
Bloodknight Studios