[Solved]Memory leak in multithreaded version

Hi,
first I want to thank you for your work, great job!

But maybe there is still one memory leak left using the multithreaded version.
I use VC9 / OGRE 1.6.2 / OgreOggSound 1.09 compiled against BOOST 1.39 and OpenAL 1.1.
All works fine except the one memory leak per created sound. Whether the sound is streamed or not.
I figured out that the memory leak is a string that is holding the path to the sound file.

The first time the memory address shows up is in:


OgreOggISound* OgreOggSoundManager::createSound(const std::string& name, const std::string& file, bool stream, bool loop, bool preBuffer)
{
//mFileName will later be the memory leak
fo->mFileName = file; // Filename to register
}

I guess this is where it should be deleted:


void OgreOggSoundManager::processQueuedSounds()
{
// Delete struct
(*i)->mFile.setNull();
// (*i)->mFileName = "DELETE ME";
// If I do this I can read DELETE ME in the output Window
OGRE_FREE((*i), Ogre::MEMCATEGORY_GENERAL);
}


1. 
   Detected memory leaks!
   Dumping objects ->
   {148983} normal block at 0x0634DA40, 48 bytes long.
   Data: <DELETE ME \level> 44 45 4C 45 54 45 20 4D 45 00 5C 6C 65 76 65 6C
   Object dump complete.
   [/list:u]
   Do you have any ideas what could cause this?
   
   Regards bophi

I don't know why this happens, as far as I'm aware this is the correct way to allocate/deallocate the memory for this structure with OGRE's memory macros. OGRE's leaks file doesn't report any leaks does it?

Thanks for your reply.
No, OGRE doesen't report any leaks.

We use this to check for leaks:

#if defined(DEBUG) | defined(_DEBUG)
_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
#endif


So what does that mean is one of them wrong?
Are OGRE´s memory macros multithread safe?

Hi Bophi,

Finally had a bit of time to take a look at this although didn't find a solution to it, however I'm not entirely sure there is a problem with the lib still.

I tried turning on the debugging as you suggested in my testdemo app and it reports 4 leaks which I haven't been able to track down, but its not connected to the sound lib. When I add/remove the sound code from the app there is no change in the memory leaks detected..

Is that debug code the only code you use to trace leaks? because that only traces allocations/deallocations made using malloc/free NOT new/delete which the lib uses. From what I read, you have to define a macro and preprocessor definition to turn on tracing of those allocations, which therefore suggest a leak somewhere else.

I do see that mFilename isn't erased immediately after OGRE_FREE() however I don't know whether this is just because the memory is left untouched but marked for re-use or, as I read somewhere else, STL deallocations are handled pretty late on so wouldn't necessarily free itself immediately

I have tried posting a query on the OGRE forums but no-one has replied, I'd be pretty confident the OGRE memory macros are thread safe and that leaks.log is reporting correctly, have you managed to get any further tracking anything down?

Regards,

Hi there,

I've taken another look at this after finding a bit of useful memory tracking code:// First simple memory leak detection for VS2005/VS2008
#if (defined( WIN32 ) || defined( _WIN32 )) && defined( _MSC_VER ) && defined( _DEBUG )
// use _crtBreakAlloc to put a breakpoint on the provided memory leak id allocation
//_crtBreakAlloc = 55002;
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
#endif

and managed to fix a minor memory leak in my test demo app, I wasn't cleaning OIS up properly. I did however, manage to confirm that with the latest code I definitely don't get any memory leaks from the lib when using my demo app

However I did come across some allocation bugs relating to EFX effect lists which I've corrected, I'm awaiting a response to a query I have about cleaning up these lists, although the fix at the moment seems to work fine but is a little odd.