Typical memory leak (not detected by emulator) | developer.brewmp.com Typical memory leak (not detected by emulator) | developer.brewmp.com

Developer

Typical memory leak (not detected by emulator)

Forums:

Can anybody explain the reason why my application fails to free memory on the device .While there are no memory leaks in the emulator .The problem is severe when the sound in the application is on .

The emulator really doesn't try to accurately emulate the way sound works, can't be trusted.
I've spent more time tweaking my SoundManager code to work correctly on all phones than any other module... urgh! I also had to work out sound leak issues with sound, assuming you isolate it to your sound system, here are some random ideas for you:
-----
Don't loop a sound by calling ISOUNDPLAYER_Play(m_pISoundPlayer); again directly on the T720 in the callback after getting a AEE_SOUNDPLAYER_DONE, this will cause a sound leak.
Instead, cue up the sound to be reloaded and played on the next tick.
Most of the problems can be fixed by having a robust cueing system so you can split up calls instead of doing Stop(), Load(), Play() at the same time.
Loading and handling the sound storage yourself (using SDT_BUFFER instead of SDT_FILE in the ISOUNDPLAYER_SetInfo) seems less error prone, even when I don't cache out the sounds but reload them for each play. (I store them in bar files and that works fine)
Also, don't trust the API docs, log the messages you get and double check everything. For instance, I keep track of if a sound is currently playing manually because EITEMBUSY on some phones isn't returned reliably on a ISOUNDPLAYER_GetInfo() call. :eek:

The emulator really doesn't try to accurately emulate the way sound works, can't be trusted.
I've spent more time tweaking my SoundManager code to work correctly on all phones than any other module... urgh! I also had to work out sound leak issues with sound, assuming you isolate it to your sound system, here are some random ideas for you:
-----
Don't loop a sound by calling ISOUNDPLAYER_Play(m_pISoundPlayer); again directly on the T720 in the callback after getting a AEE_SOUNDPLAYER_DONE, this will cause a sound leak.
Instead, cue up the sound to be reloaded and played on the next tick.
Most of the problems can be fixed by having a robust cueing system so you can split up calls instead of doing Stop(), Load(), Play() at the same time.
Loading and handling the sound storage yourself (using SDT_BUFFER instead of SDT_FILE in the ISOUNDPLAYER_SetInfo) seems less error prone, even when I don't cache out the sounds but reload them for each play. (I store them in bar files and that works fine)
Also, don't trust the API docs, log the messages you get and double check everything. For instance, I keep track of if a sound is currently playing manually because EITEMBUSY on some phones isn't returned reliably on a ISOUNDPLAYER_GetInfo() call. :eek:

I had such problem once on the T720 because I SYSFREE an IIMAGE object by mistake... It never showed up memory leak on the emulator but it did on the real device.

I had such problem once on the T720 because I SYSFREE an IIMAGE object by mistake... It never showed up memory leak on the emulator but it did on the real device.

ISOUNDPLAYER_GetInfo seems to return EITEMBUSY on some midi sounds when played out of memory. The same midi sounds work fine when played form a file. The midi files that seem to have this most often are those of of odd length. Eventually the sound finishes but it is quite a while later. Has anyone found a reason why midi sounds played out of memory do not "finish" properly?
I tried increasing the size and adding an even number and filling with zero but still get the same result.

ISOUNDPLAYER_GetInfo seems to return EITEMBUSY on some midi sounds when played out of memory. The same midi sounds work fine when played form a file. The midi files that seem to have this most often are those of of odd length. Eventually the sound finishes but it is quite a while later. Has anyone found a reason why midi sounds played out of memory do not "finish" properly?
I tried increasing the size and adding an even number and filling with zero but still get the same result.

i usually get the opposite leaks on the simulator when it uses sounds and not on the phone.
also the simulator doesn't track memory leaks if the skin is using the windows heap

i usually get the opposite leaks on the simulator when it uses sounds and not on the phone.
also the simulator doesn't track memory leaks if the skin is using the windows heap

I think you can always try do some sofware engineering tricks to get memory leaks
like #define MALLOC(p) reg(MALLOC(x));
since preprocessor can't be recursive it will call your function reg that will receives the real MALLOC, register the pointer and return its value
obvious do the same ideia for FREE(), deregistering your pointer
at the end of the aplicantion just check if your list is empty, if its not it has the memory you leaked
additionaly you could add some more tricks to know which call caused the leak and etc..

I think you can always try do some sofware engineering tricks to get memory leaks
like #define MALLOC(p) reg(MALLOC(x));
since preprocessor can't be recursive it will call your function reg that will receives the real MALLOC, register the pointer and return its value
obvious do the same ideia for FREE(), deregistering your pointer
at the end of the aplicantion just check if your list is empty, if its not it has the memory you leaked
additionaly you could add some more tricks to know which call caused the leak and etc..

Ronin,
That's not a software engineering trick - that's a hack!
What you really want to do is avoid malloc and free altogether and use NEW and DELETE instead, which you can easily and properly overload. That way you have complete control over your memory management and can include tracking and reporting capabilities as you like.

Ronin,
That's not a software engineering trick - that's a hack!
What you really want to do is avoid malloc and free altogether and use NEW and DELETE instead, which you can easily and properly overload. That way you have complete control over your memory management and can include tracking and reporting capabilities as you like.

elogg@genplay.com wrote:ISOUNDPLAYER_GetInfo seems to return EITEMBUSY on some midi sounds when played out of memory. The same midi sounds work fine when played form a file. The midi files that seem to have this most often are those of of odd length. Eventually the sound finishes but it is quite a while later. Has anyone found a reason why midi sounds played out of memory do not "finish" properly?
I tried increasing the size and adding an even number and filling with zero but still get the same result.
I've discovered a possible cause for this, although I haven't compared playing from memory vs file.
The files that play for a long time before the device detects the end of them aren't properly "terminated", for lack of a better term. What I mean is that every channel must have a "NoteOff" as its last event, or you see this situation. Presumably the soundplayer uses the last NoteOff event as a cue to stop. If it isn't there I suspect we're seeing undefined behaviour and we're lucky it stops at all.
Look at those files in a MIDI sequencer, and there's a good chance one of the channels ends with a modulation event or some such. Inserting a NoteOff event, however that's done, should fix the problem.

elogg@genplay.com wrote:ISOUNDPLAYER_GetInfo seems to return EITEMBUSY on some midi sounds when played out of memory. The same midi sounds work fine when played form a file. The midi files that seem to have this most often are those of of odd length. Eventually the sound finishes but it is quite a while later. Has anyone found a reason why midi sounds played out of memory do not "finish" properly?
I tried increasing the size and adding an even number and filling with zero but still get the same result.
I've discovered a possible cause for this, although I haven't compared playing from memory vs file.
The files that play for a long time before the device detects the end of them aren't properly "terminated", for lack of a better term. What I mean is that every channel must have a "NoteOff" as its last event, or you see this situation. Presumably the soundplayer uses the last NoteOff event as a cue to stop. If it isn't there I suspect we're seeing undefined behaviour and we're lucky it stops at all.
Look at those files in a MIDI sequencer, and there's a good chance one of the channels ends with a modulation event or some such. Inserting a NoteOff event, however that's done, should fix the problem.