Ogg memory leak not shown in Bmax...

A framework customer has just told me about a memory leak when playing oggs in my framework. Or at least it looks like a leak in Task Manager but NOT in BMax, it's weird. Read on...


If you run the AOTMG demo:

http://www.greyaliengames.com/aotmg/aotmg041.zip (5.74Mb)

and press D for debug, you'll see some stats inc. memory. Also press Ctrl+Alt+Del del and look at the memory in task manager. Then basically click play, press enter to choose a level, and then press escape to quit to the menu. Keep repeating this and the memory in task manager will go up and up, yet the Bmax memory figure GCMemAlloced will stay constant. Why is this? Anyone know. Thanks very much.

What does your code do?
Or asked in a different way: is StopChannel called on the running channel before leaving to menu? (or setpaused on leave and reenter)

I'm mainly asking that in case it does just call TSound.Play() over and over without actually stopping running channel and without specifying the previously allocated channel as alloced_channel to the play method.

Probably because the GC amount is only based on max-managed memory, and not external C-allocated memory (which I imagine is where memory is allocated by the ogg loader.

The same channel is reused so it shouldn't be that. hmm maybe I should make a test app.

OK the problem WAS the fact that I was reusing the channel, by Pausing it (because StopChannel frees the channel) and then loading some new music and playing it on the same channel. For some reason that doesn't free up the ogg properly! So now, I'm using StopChannel, then reallocating a NEW music channel and the loading in the new music.

Is this behaviour a Bmax bug? It sure feels like it.

I thought reusing channel is meant for playing the same track again ...

But the not freeing is definitely a memory leak, no mather if using a different sounds channel is correct usage or not.

yeah I was reusing the channel to play different tracks, and reusing the same MusicSample variable so basically there shouldn't be a memory leak but there is...

Thing is, this memory leak is a HUGE one compared to most minor memory leaks as oggs when uncompressed are MBs big!