Steve Rencontre
Guest
|
Posted:
Tue Dec 20, 2005 5:30 pm Post subject:
Memory leak in WMA9 Voice codec |
|
|
I have a program which regularly creates Windows Media Audio 9 voice
encoder DMO objects and as it runs, its memory footprint just keeps
growing :-(
The codec has a memory leak related to setting the output type. The
following program demonstrates it:
#define _WIN32_WINNT 0x0501
#define STRICT
#include <windows.h>
#include <dmo.h>
#include "wmcodecconst.h"
int main ()
{
IMediaObject *mo;
DMO_MEDIA_TYPE dmt;
::CoInitializeEx (0, COINIT_MULTITHREADED);
::CoCreateInstance (CLSID_CWMSPEncMediaObject, 0,
CLSCTX_INPROC_SERVER, __uuidof (IMediaObject),
(void **) &mo);
mo->GetOutputType (0, 0, &dmt);
mo->SetOutputType (0, &dmt, 0);
::MoFreeMediaType (&dmt);
mo->Release();
::CoUninitialize ();
}
If you run this under Windbg and break just before the end, then issue
the !heap -l command, you can see the leaks. (TTBOMK, Visual Studio
Debugger has no equivalent of this command. If anyone knows better, do
please tell me!)
For example,
0:000> !heap -l
Heap 00140000
Heap 00240000
Heap 00250000
Heap 00320000
Heap 00340000
Heap 00370000
Scanning VM ...
Entry User Heap Segment Size Prev Unused Flags
------------------------------------------------------------------------
003275a8 003275b0 00320000 00320000 58 80 18 busy extra fill
00327a38 00327a40 00320000 00320000 28 88 18 busy extra fill
0032a4c0 0032a4c8 00320000 00320000 240 440 1c busy extra fill
0032ba00 0032ba08 00320000 00320000 850 440 1c busy extra fill
0090c528 0090c530 00320000 008f0000 88 88 18 busy extra fill
0090d060 0090d068 00320000 008f0000 80 240 18 busy extra fill
0090d0e0 0090d0e8 00320000 008f0000 60 80 18 busy extra fill
0090d140 0090d148 00320000 008f0000 140 60 1c busy extra fill
0090d280 0090d288 00320000 008f0000 c0 140 1c busy extra fill
0090d340 0090d348 00320000 008f0000 c0 c0 1c busy extra fill
0090d400 0090d408 00320000 008f0000 88 c0 18 busy extra fill
0090d488 0090d490 00320000 008f0000 88 88 18 busy extra fill
0090d548 0090d550 00320000 008f0000 240 38 1c busy extra fill
0090d788 0090d790 00320000 008f0000 140 240 1c busy extra fill
0090d8c8 0090d8d0 00320000 008f0000 140 140 1c busy extra fill
0090da08 0090da10 00320000 008f0000 88 140 18 busy extra fill
0090db48 0090db50 00320000 008f0000 c0 b8 18 busy extra fill
0090dc08 0090dc10 00320000 008f0000 240 c0 1c busy extra fill
0090de48 0090de50 00320000 008f0000 140 240 18 busy extra fill
19 leaks detected.
Commenting out the SetOutputType() call makes them go away, and
similarly, changing the encoder (eg, by changing
CLSID_CWMSPEncMediaObject to CLSID_CWMAEncMediaObject) shows no leak.
Things that /don't/ make any difference are changing the COM threading
model or even not bothering to call MoFreeMediaType(). (The latter is a
leak, but of a different sort. It doesn't show up as an unreferenced
heap item because it /is/ still referenced.)
Anyone from Microsoft able to help? Anyone else seen this and got a
workaround?
All suggestions gratefully received, TIA.
|
|