none
Memory leak in basic directshow code

    Question

  • We are developing an application that uses Directshow platform for viewing live video. As user needs to cycle between different video sources, we need to rebuilds the graph often.

    The problem we are experiencing is that the memory usage of our application steadily grows all the time (no memory leak was detected by VS when application exits). So we tried to nail down the issue by isolating codes down to its simplest form. And to our surprise, even the following code exhibits memory growth/leak:

    	CoInitialize(0);
    
    	while(WAIT_TIMEOUT == WaitForSingleObject(gs_evExit, 300))
    	{
    		CComPtr<IGraphBuilder> pGraph;
    		CoCreateInstance(CLSID_FilterGraph,
    					  NULL, CLSCTX_INPROC_SERVER, 
    					  IID_IGraphBuilder, (void **)&pGraph);
    	}
    
    	CoUninitialize();
    
    The above code runs in a console application, the memory footprint grows from about 1.5M to 3.2M within 2.5 hours.

    Am I missing something here? or Directshow graph is not designed for frequent rebuilt?

    Below is the entire code for the console application:

    #include "stdafx.h"
    #include <iostream>
    #include "Dshow.h"
    
    #pragma comment(lib, "Strmiids.lib")
    
    static HANDLE gs_evExit = NULL;
    
    DWORD WINAPI GraphTest(LPVOID lpContext)
    {
    	CoInitialize(0);
    
    	while(WAIT_TIMEOUT == WaitForSingleObject(gs_evExit, 300))
    	{
    		CComPtr<IGraphBuilder> pGraph;
    		CoCreateInstance(CLSID_FilterGraph,
    					  NULL, CLSCTX_INPROC_SERVER, 
    					  IID_IGraphBuilder, (void **)&pGraph);
    	}
    
    	CoUninitialize();
    
    	return 0;
    }
    
    int _tmain(int argc, _TCHAR* argv[])
    {
    	gs_evExit = ::CreateEvent(NULL, TRUE, FALSE, NULL);
    	HANDLE hThread = ::CreateThread(NULL, 0, GraphTest, NULL, 0, NULL);
    
    	while(std::cin.get() != 'q') Sleep(1);
    
    	::SetEvent(gs_evExit);
    	WaitForSingleObject(hThread, INFINITE);
    	CloseHandle(hThread);
    	CloseHandle(gs_evExit);
    
    	return 0;
    }
    
    

    • Edited by LazyInNet Tuesday, March 09, 2010 9:24 AM add border to code section
    Tuesday, March 09, 2010 9:22 AM

Answers

  • I think you are correct here and the memory leak bug exists (I'll forward to MS), thank you for pointing this out.

    Also, CLSID_FilterGraphNoThread does not show this problem, so can be used for quick fix before the problem is fixed by MS.

    http://alax.info/blog/tag/directshow
    • Marked as answer by LazyInNet Thursday, March 11, 2010 9:17 AM
    Wednesday, March 10, 2010 4:46 AM
  • I'd suggest that if it is critical for you, then see if you can rework your application using NoThread version of the FGM or instead of releasing the FGM instance try reusing it by removing all filters and adding new. The memory leak rate does not look fatal (unless leaked graph keeps references to filters it owned also).
    http://alax.info/blog/tag/directshow
    • Marked as answer by LazyInNet Thursday, March 11, 2010 9:17 AM
    Wednesday, March 10, 2010 10:58 AM

All replies

  • The above code runs in a console application, the memory footprint grows from about 1.5M to 3.2M within 2.5 hours.

    Am I missing something here? or Directshow graph is not designed for frequent rebuilt?

    How do you check memory footprint?

    http://alax.info/blog/tag/directshow
    Tuesday, March 09, 2010 10:23 AM
  • How do you check memory footprint?

    http://alax.info/blog/tag/directshow
    Here's screens shot image of my task manager over a 30 min period, and as you can see the memory footprint increased by about 400k:



    This time I also performed the same test on a WinXP machine, and interestingly there is no significant memory increase! See below, the screen shot is taken at about the same time as the ones taken on Win7 machine:


    I will test it again on Vista and see what happens.
    Tuesday, March 09, 2010 8:29 PM
  • Another interesting thing to note is the difference in CPU usage. My Win7 machine has a Core 2 Quad CPU, where as the XP machine only has an old Pentium 4. But the CPU usage in Win7 hovers around 5% where as the XP machine has almost no CPU consumption...
    Tuesday, March 09, 2010 8:34 PM
  • I think you are correct here and the memory leak bug exists (I'll forward to MS), thank you for pointing this out.

    Also, CLSID_FilterGraphNoThread does not show this problem, so can be used for quick fix before the problem is fixed by MS.

    http://alax.info/blog/tag/directshow
    • Marked as answer by LazyInNet Thursday, March 11, 2010 9:17 AM
    Wednesday, March 10, 2010 4:46 AM
  • Thanks.

    Seems to be a Windows 7 only issue. I tested again today on a laptop running Win7 32 bit, and a desktop running Vista, and the memory issue only happens in the Win7 laptop.

    I never used CLSID_FilterGraphNoThread before, and there doesn't seem to be many examples around. Just wondering what's a good practice? Shall I

    1. run a dedicated thread to create the graph object, and do the message pumping until being signaled to exit, and then access the graph object from other threads (in this case I don't need to change too much of my code)? or,
    2. fit message pumping into my thread that accesses the graph object? or,
    3. create the graph object in the MFC main thread, then I suppose the MFC message pumping would handle the graph messages, right? is there any potential issue here?
    Wednesday, March 10, 2010 9:11 AM
  • I'd suggest that if it is critical for you, then see if you can rework your application using NoThread version of the FGM or instead of releasing the FGM instance try reusing it by removing all filters and adding new. The memory leak rate does not look fatal (unless leaked graph keeps references to filters it owned also).
    http://alax.info/blog/tag/directshow
    • Marked as answer by LazyInNet Thursday, March 11, 2010 9:17 AM
    Wednesday, March 10, 2010 10:58 AM
  • Yes, I will try to reuse the filter graph object and see how it goes. Thank you very much for your help. Hopefully MS will fix this issue soon.
    Thursday, March 11, 2010 9:17 AM
  • I am seeing the same problem and the no thread CLSID is not an option.

    Is there a hotfix available for this problem and or is it corrected in Windows 7 SP1?

    This is a severe issue when playing multiple files creating and releasing multiple graphs over time.


    Graphics Point Engineering
    Friday, January 28, 2011 4:04 AM
  • I am not really sure what kind of leak your are seeing. On the one hand you/OP create a filter graph manager object and it has its internal resources which may have extended lifetime and outlive FGM itself (such as, for example, caches or background threads). It is no exactly a bug itself and requires more detailed research to tell if this is expected behavior or not.

    On the other hand, if you not only create FGM but also render files, internally filters and other objects are instantiated and may cause memory leaks behind the curtains. As you are seeing the process from the point of view of creating and releasing filter graph, you may want to attribute this kind of leak to filter graph manager and DirectShow as a subsystem.

    This is exactly the situation I saw a few weeks ago with Windows XP and Intel Indeo codec taken for YUV conversion: being created and released, it leaved a small memory leak. Running a loop with creating graphs, rendering media and releasing graphs (without even running the graph) exhibited accumulated memory consumption and memory leak.

    I would suggest that you check the problematic scenario and get more detail for further troubleshooting. I am neither aware of fixes, nor I am aware of a proof that shows DirectShow core components as leaking.
    http://alax.info/blog/tag/directshow
    Saturday, January 29, 2011 2:30 PM