[SOLVED] Advice for robust leaks?

[abecam]

Having a lot of fun with Ogre and OgreNewt (thanks all !), I was seeking for my leaks this week, and I went from hundred to two , so that's nice.
Then the two I have are that:

Code: Select all

2 memory leaks found:

Alloc.   Addr       Size       Addr       Size                        BreakOn BreakOn              
Number Reported   Reported    Actual     Actual     Unused    Method  Dealloc Realloc Allocated by 
------ ---------- ---------- ---------- ---------- ---------- -------- ------- ------- --------------------------------------------------- 
029555 0x08F066C0 0x00000160 0x08F066B0 0x00000180 0x00000000 new         N       N    ogrewin32platformdll.cpp(91) Ogre::createPlatformInputReader
029556 0x08F06870 0x00000014 0x08F06860 0x00000034 0x00000000 new         N       N    ??(0) ??

And I really know that there isn't a ogrewin32platformdll.cpp problem, because I achieved to have no leak before, and the ??(0)?? makes me feel I am just doing "something in the void", and that these two leaks are just one stupid delete/repeated new/... that gives a nice confusion in my memory .
Then I have looked for all my new and delete, isolated the most critical, and I cannot find the source of my problem. So I was just wondering if some persons here simply know which kind of thing I should look for? Or should I just keep tracking all the allocation/deallocation (and consider the indirect creations maybe).

[M]

Check that every call to InputReader* inputReader = PlatformManager::getSingleton().createInputReader(); has a corresponding
PlatformManager::getSingleton().destroyInputReader(inputReader); somewhere.

[abecam]

The funny thing is that I do not use this method (I derived my code from an example, I keep most of the listener part as it, as it was just perfect for me)... And it seems to be linked to the Listener which has proved to be leak-safe (for now). Then it might be something to do anyway (look from where come this method to see where might be the problem). But it cannot be directly that...
My question is very general, if some persons have experienced this kind of indirect nasty leaks, and this unknown one (and I still think they can be linked), to give some advices from their experience. I guess it might be useful for everyone.

[sinbad]

Perhaps you are using an EventProcessor, if so, make sure you destroy it.

[abecam]

Aaaargh I use none of them (I did a search on the whole project). I guess I just have push one extra delete or something like that, and my app goes banana then. It seems that the memory leaks report is robust for all the "new", including the extra-ones (a bad loop on new with the same variables), so it might be with delete or with the use of one pointer before initialisation or after delete... 4 days without a look at it, I am fresh to look back !

[abecam]

Then... Actually I didn't use these, but ONewt did... And a simple destroyInputReader was missing (maybe my version of ONewt was old, I will see in the dedicated forum).
So here it is:

Code: Select all

 ---------------------------------------------------------------------------------------------------------------------------------- 
|                                          Memory leak report for:  06/12/2006 20:15:28                                            |
 ---------------------------------------------------------------------------------------------------------------------------------- 


Congratulations! No memory leaks found!

Thanks !!!!