[Solved] Memory leak in ATL ActiveX project

Hi ,
I tried to use OgreOggSound with my project( ATL ActiveX ), but it's strange enough that the application occured memory leak in OGGSOUND_THREADED or non OGGSOUND_THREADED mode...
but when i tried other win32 applications , they were all very OK !

The ATL ActiveX environment is : VC9.0 + ATL9.0 + OGRE1.4.9 + OgreOggSound 1.07...

If someone met the same problem before, let's discuss about it... maybe we could find the answer....

Thanks....

Hmm, thats a strange one, and difficult for me to debug without a similar project setup.

If you could do some investigation and pinpoint the problem that would be great, unless you could put together a simple example which replicates the problem

Kind Regards,

Hmm, thats a strange one, and difficult for me to debug without a similar project setup.

If you could do some investigation and pinpoint the problem that would be great, unless you could put together a simple example which replicates the problem


Maybe it will be a painful thing to pinpoint the problem, because in some normal win32 application, we can use the VLD(Visual Leak Detector) to dig in the code and find the smelly segment, but in the COM project, VLD maybe work helpless...

I found that, I used the "OgreOggSoundManager::createSound" to create a "OgreOggISound" instance, if i didn't call the "OgreOggSoundManager::playSound" , in this condition, it seemed no memory leak at all.... But when i called the "OgreOggSoundManager::playSound" to play the "OgreOggISound" then i closed the application sometime later, memory leak appear...

I have used the "boost::shared_ptr" to control the life of "OgreOggSoundManager", and i debug into the "OgreOggSoundManager::~OgreOggSoundManager()" and "OgreOggSoundManager::_release()", all things have gone with the right way....but why did the application occured memory leak ?

********************************************************************************************************
Detected memory leaks!
Dumping objects ->
{6024} normal block at 0x00E3BB88, 8 bytes long.
Data: <P > 50 1D 12 04 00 00 00 00
{5688} normal block at 0x00DEDDA0, 16 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.
********************************************************************************************************

Aha...anyway...thanks very much ....to you and the cool project...

Hi Kamaliang,

I've committed an update to the library which may fix your issue, I've added Ogre's Memory allocation tracking support to the library, so now when activated allocations are tracked and reported in the OgreLeaks.log.

Obviously I checked it out first and came across two possible leak issues which I've hopefully fixed now, maybe you can try the latest version and report back

FYI, the leaks could stem from the following conditions:

* Exited program before a sound queued to play had actually been played
* Played a non-streamed sound

If you have done either of these it could be solved....

Thanks, stickymango...I appreciate so much for your good job...
But i was ashamed of that the ATL Project uses OGRE1.4.9, and i don't want to change OGRE the newest one(cause it will need sometime to work it well)...

So the new code you post to the SVN today, I can't test it and feed back now... but sure i will try it some time later!

Sorry...please forgive me...

P.S: maybe you can use smart ptr of BOOST rather than the OGRE's... i just suggest that..please don't mind...

Ah right okay,

you could modify the SVN version to work on 1.4.9 easily by removing a couple of virtual functions..

anyway, if you get round to it let me know what happens,

Thanks.

Ah right okay,

you could modify the SVN version to work on 1.4.9 easily by removing a couple of virtual functions..

anyway, if you get round to it let me know what happens,

Thanks.

hmm....you see, not only "removing a couple of virtual functions"...cause the code you post today include many "OgreMemoryAllocator"(these mechanics is in OGRE1.6.0 or later) and so on that control the memory managing...

So...If i modify the svn code you post today , that will be a fool thing to do it...cuase it will be restituted the code like before...

thanks...

Yeah, I thought of that just after I replied, it wouldn't be a difficult job to convert the memory management code if I have time I might create a 1.4.9 compatible version..

[Edit] Added a .zip download of an Eihort compatible version of the latest code, if its use give it a whirl...

These days i encapsulated the OgreOggSound into a plugin dll for the ATL project, rather than embeded it directly into the code...

And in this condition, memory leak disappeared...and it works well...

It's strange enough... but it seems that this problem has been solved unconsciously...

Very strange but glad its now sorted, at least you prompted me to do a more thorough check of the code and in the process helped me plug two undiscovered leaks so thanks!