Unmanaged memory leak when transitioning between WPFChromium-based controls

2 posts, 0 answers
  1. Helder Pinto
    Helder Pinto avatar
    12 posts
    Member since:
    Jul 2009

    Posted 16 Mar 2011 Link to this post

    Hi!

    I am using RadTransitionControl to perform transitions between heterogeneous views that generally contain pure WPF controls, but that sometimes also use interop-based controls.

    I detected recently an unmanaged memory leak in my application when using RadTransition with a WPFChromium-based control (http://wpfchromium.codeplex.com). The application is stable when performing transitions between pure WPF controls. It is still stable when performing transitions between views that contain DirectShow-based controls. However, whenever I use WPFChromium in my transitions, there is a significant, constant unmanaged memory leak (about 20MB/hour with transitions occuring every 30 seconds).

    If I take RadTransitionControl off my application, it becomes stable, even when using WPFChromium.

    The interesting part is that it does not seem a transition-related problem, because if I keep setting the Content property always to the same view (i.e., the transition does not occur), the unmanaged leak persists. It seems that just using the RadTransitionControl as a container of WPFChromium triggers the leak.


    I collected heap data with WinDgb, and there are two kinds of memory blocks leaking:

    a) 48 bytes long blocks leaking about 100.000 units every hour. This is the code stack leaking those blocks:
            7744dd6c ntdll!RtlAllocateHeap+0x00000274
            6ebe13ff wpfgfx_v0300+0x000013ff
            6ebe7e69 wpfgfx_v0300!MilChannel_CommitChannel+0x0000008b
            6ebe8940 wpfgfx_v0300!MilChannel_CommitChannel+0x00000b62
            6ebe89bf wpfgfx_v0300!MilChannel_CommitChannel+0x00000be1
            6ebe891b wpfgfx_v0300!MilChannel_CommitChannel+0x00000b3d
            6ebe88ec wpfgfx_v0300!MilChannel_CommitChannel+0x00000b0e
            6ebedede wpfgfx_v0300!MilChannel_AppendCommandData+0x00000961
            6ebec992 wpfgfx_v0300!MilComposition_PeekNextMessage+0x00000078
            6ebec9b3 wpfgfx_v0300!MilComposition_PeekNextMessage+0x00000099
            6ebe73c8 wpfgfx_v0300!MilResource_SendCommand+0x000024d4
            6ebe7437 wpfgfx_v0300!MilResource_SendCommand+0x00002543
            6ebe74b6 wpfgfx_v0300!MilResource_SendCommand+0x000025c2

    b) 3686384 bytes long blocks leaking about 2/3 units every hour. This is the code stack leaking those blocks:

            7744dd6c ntdll!RtlAllocateHeap+0x00000274
            73c62423 WindowsCodecs!WPF::ProcessHeapImpl::Alloc+0x00000016
            73c63491 WindowsCodecs!WPF::HrMalloc+0x0000004b
            73c663ba WindowsCodecs!CSystemMemoryBitmap::HrInit+0x0000006c
            73d0d5b9 WindowsCodecs!CLateBitmap::FinalizeBitmap+0x0000002e
            73d0d6b9 WindowsCodecs!CLateBitmap::CopyPixels+0x0000004a
            73d00f7b WindowsCodecs!IWICBitmapSource_CopyPixels_Proxy+0x00000023



    Are you aware situations leading to unmanaged memory leaks with WPFChromium or any other C++ wrapper-based control? Do you suggest any work-around or further debugging?


    Thanks!

    Helder Pinto
  2. Helder Pinto
    Helder Pinto avatar
    12 posts
    Member since:
    Jul 2009

    Posted 18 Mar 2011 Link to this post

    Hi, again!


    Forget about the last message regarding unmanaged leaks with WPFChromium inside Telerik's RadTransitionControl. I've further isolated the problem and I am sure the leak is not caused by any of the mentioned components.

    Sorry for the inconvenience.

    Regards,

    Helder
  3. UI for WPF is Visual Studio 2017 Ready
Back to Top