Home › Forums › OpenEars plugins › RapidEars startRealtimeListeningWithLanguageModelAtPath memory leaks › Reply To: RapidEars startRealtimeListeningWithLanguageModelAtPath memory leaks
Hi Laurent,
Take a look at what I wrote previously – to investigate a memory issue when I’m not aware of any existing issue, I need to hear about specifics that you are seeing using Instruments. That means telling me something about which specific objects you see as being reported as growing indefinitely, why it doesn’t seem right for them to use the memory they use, and by what amount over what time period they grow.
When I run the sample app with your code, I see correct behavior: there are some micro leaks from Flite and Pocketsphinx, and the OpenEars’ classes memory usage is reasonably frugal during listening, and extra memory is immediately released after a large amount of it is used during the final recognition. When listening is stopped, it is all released. At no time is an unusual amount of memory allocated (given the task). I don’t see any data in here yet that would lead to a correlation with your crash. I think it’s important to start by recreating the crash condition and look at the data you see yourself, rather than working from the opposite direction of expecting a correlation without information about it.
A reason that OpenEars or RapidEars will correctly increase the memory footprint over the life of a listening session (not leak) is because the data object where the utterance is held before recognition eventually will become large enough to hold the longest utterance that was spoken in the session. That isn’t a leak, it’s just a single buffer finding the ceiling needed in order to hold the full amount of data it is being asked to hold. This isn’t a sign of a problem since it can be released when it isn’t being used. If you watch the persistent heap bytes for a while in Instruments you will also see the numbers decrease when there is no speech (and decrease dramatically when listening is stopped), if you wait a while.
I am still up for looking into very specific reports (which include full logging, specific objects, etc) if you can recreate your crash and have some evidence that it relates to one of the libraries.