Client OS: Windows 8.1 64-bit
CEF version: 3.1650.1503
Xilium.CefGlue downloaded revision: e4777a271575
Part of testing for my product, I run it under the application verifier that comes with the Windows SDK. I enable all of the basic checks in the application verifier (exceptions, handles, leaks, locks, etc). In order to view the output of the verifier, I use the global flags utility to start my application running under WinDbg.
My application runs fine under the verifier, no problem. CEF is working fine - no problem. No issues from the app verifier while the application is running and loading webpages in CEF. Excellent.
Closing the application though, is where much of the app verifier results will show. So I close my application - BOOM. There are a bazillion heap leaks, all with the same/similar stack trace. No heap leaks if you just load the CEF run-time in the process. They only happen once you start actually loading websites using CEF.
To make sure my application was not the problem, I have tested using the client app from CefGlue and the WinForms demo app from CefGlue - the same heap leaks occur under the same app verifier settings. Now, I also tested the native CEF demo application (which completely eliminates CefGlue - no heap leaks with that one!!).
Here is an example verifier stop message about a heap leak:
- Code: Select all
=======================================
VERIFIER STOP 00000900: pid 0x458: A heap allocation was leaked.
1E650D18 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
03FA1C14 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
2319AFE8 : Address of the owner dll name. Run du <address> to read the dll name.
5B470000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.
=======================================
Now, here is the allocation stack for one of them (they are all the same - and you can keep pressing F5 over and over, there's a bazillion):
- Code: Select all
0:000> dps 03FA1C14
03fa1c14 03f15a44
03fa1c18 0000f803
03fa1c1c 00200000
03fa1c20 5d3f8d9c verifier!AVrfDebugPageHeapAllocate+0x23c
03fa1c24 77993165 ntdll!RtlDebugAllocateHeap+0x32
03fa1c28 77930934 ntdll!RtlpAllocateHeap+0x411fc
03fa1c2c 778ef584 ntdll!RtlAllocateHeap+0x14c
03fa1c30 5d90a792 vrfcore!VfCoreRtlAllocateHeap+0x16
03fa1c34 5d460196 vfbasics!AVrfpRtlAllocateHeap+0xe2
03fa1c38 7723141d KERNELBASE!LocalAlloc+0x88
03fa1c3c 5d460c4d vfbasics!AVrfpLocalAlloc+0xa8
03fa1c40 5b47e803 d3d9!D3D9CreateDirectDrawObject+0x5b
03fa1c44 5b47d25f d3d9!FetchDirectDrawData+0xeb
03fa1c48 5b47e70a d3d9!InternalDirectDrawCreate+0x150
03fa1c4c 5b47fd33 d3d9!CEnum::CEnum+0x232
03fa1c50 5b4801d7 d3d9!Direct3DCreate9Impl+0x80
03fa1c54 5b48027e d3d9!Direct3DCreate9Ex+0x27
03fa1c58 121c9e22 libcef!ui_surface_d3d9_utils::CreateDevice+0x52 [c:\cef\workspace\cef3-windows-1650\download\chromium\src\ui\surface\d3d9_utils_win.cc @ 40]
03fa1c5c 121b9447 libcef!PresentThread::ResetDevice+0x187 [c:\cef\workspace\cef3-windows-1650\download\chromium\src\ui\surface\accelerated_surface_win.cc @ 224]
03fa1c60 121b90fc libcef!PresentThread::InitDevice+0xcc [c:\cef\workspace\cef3-windows-1650\download\chromium\src\ui\surface\accelerated_surface_win.cc @ 197]
03fa1c64 121be169 libcef!AcceleratedPresenter::DoReleaseSurface+0x39 [c:\cef\workspace\cef3-windows-1650\download\chromium\src\ui\surface\accelerated_surface_win.cc @ 921]
03fa1c68 121c618b libcef!base::internal::RunnableAdapter<void (__thiscall AcceleratedPresenter::*)(void)>::Run+0x1b [c:\cef\workspace\cef3-windows-1650\download\chromium\src\base\bind_internal.h @ 134]
03fa1c6c 121c5f2a libcef!base::internal::InvokeHelper<0,void,base::internal::RunnableAdapter<void (__thiscall AcceleratedPresenter::*)(void)>,void __cdecl(AcceleratedPresenter * const &)>::MakeItSo+0x1a [c:\cef\workspace\cef3-windows-1650\download\chromium\src\base\bind_internal.h @ 872]
03fa1c70 121c5b95 libcef!base::internal::Invoker<1,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall AcceleratedPresenter::*)(void)>,void __cdecl(AcceleratedPresenter *),void __cdecl(AcceleratedPresenter *)>,void __cdecl(AcceleratedPresenter *)>::Run+0x45 [c:\cef\workspace\cef3-windows-1650\download\chromium\src\base\bind_internal.h @ 1169]
03fa1c74 10228aef libcef!base::Callback<void __cdecl(void)>::Run+0x2f [c:\cef\workspace\cef3-windows-1650\download\chromium\src\base\callback.h @ 396]
03fa1c78 102e1f43 libcef!base::MessageLoop::RunTask+0x2d3 [c:\cef\workspace\cef3-windows-1650\download\chromium\src\base\message_loop\message_loop.cc @ 493]
03fa1c7c 102e22c4 libcef!base::MessageLoop::DeferOrRunPendingTask+0x34 [c:\cef\workspace\cef3-windows-1650\download\chromium\src\base\message_loop\message_loop.cc @ 506]
03fa1c80 102e2810 libcef!base::MessageLoop::DoWork+0xe0 [c:\cef\workspace\cef3-windows-1650\download\chromium\src\base\message_loop\message_loop.cc @ 617]
03fa1c84 10382f7b libcef!base::MessagePumpDefault::Run+0xbb [c:\cef\workspace\cef3-windows-1650\download\chromium\src\base\message_loop\message_pump_default.cc @ 32]
03fa1c88 102e1ad7 libcef!base::MessageLoop::RunInternal+0xf7 [c:\cef\workspace\cef3-windows-1650\download\chromium\src\base\message_loop\message_loop.cc @ 441]
03fa1c8c 102e18ae libcef!base::MessageLoop::RunHandler+0x2e [c:\cef\workspace\cef3-windows-1650\download\chromium\src\base\message_loop\message_loop.cc @ 414]
03fa1c90 103523c9 libcef!base::RunLoop::Run+0x29 [c:\cef\workspace\cef3-windows-1650\download\chromium\src\base\run_loop.cc @ 48]
So clearly there is a leak somewhere. There's nothing about CefGlue in the stack trace which is very weird, but it does not occur with the native CEF client. IS this the right place to post this? I could have posted it on the CEF web site, but they probably wouldn't be able to reproduce it (I certainly couldn't just with CEF and no CefGlue).