BdC wrote:I can't use the fully native cefclient.exe for the render process as I have a C# V8 context handler in the render processes and messaging between render and browser process using google IPC. I did solve the issue by forcing a GC.Collect in the render process and memory now stabilizes around 180MB (the only change was to call GC.Collect at each V8 context destroy callback). If I do GC.Collect with the optimize flag (so that GC can choose to collect or not) or if I never call it, then memory increases to about 1.5GB and the process self terminates. I know the GC is not necessarily called from the message loop, but I think it uses it to figure out how busy the process is and if it's a good time to collect (I could be wrong, I'm a c# novice but a c++ master). At least it seems to me like automatic GC is not working in render process, as if I add the optimize flag the fix doesn't work and the process never reclaims any memory (same as never calling GC.Collect at all), but if I force collect, then it works fine. Also worth noting, in single process mode, there is no leak and we don't need to force GC.Collect, it just works, but since we also occasionally have no active CefWebBrowser this no longer works with the latest 904 Cef build and is no longer a viable alternative so we need to move to multi-process with forced GC.Collect to get around the leak.
By the way, thanks a lot for your quick responses and support.
What .NET version is used i.e. CLR2 or CLR4?
It will be good if you can provide simple reproduction sample about this issue.