CefClent subprocess commandline gpu args

[Mayhew]

I'm comparing cefclient's subprocess commandline args for the renderer and gpu-process on windows (CEF revision 3.2062.1876) to mine and there are quite a few differences. CefClient has things like -supports-dual-gpus=false --gpu-driver-bug-workarounds=<some value> --gpu-vendor-id -- device-scale-factor, etc.

No matter how I seem to set my Cef and browser settings my sub-processes never launch with those. My code mimics CefClient pretty closely in winMain(). I'm launching CefClient with no commandline args so I assume all settings are default. I did the same with my app.

Is there something obvious that I'm missing?

[Mayhew]

My mistake. The Win Task Manager was simply cutting off the commandline args due to my passing locals and log paths in. Once I stopped in the debugger and inspected the actual command line parameter in main I could see those being set properly.

[magreenblatt]

Process Explorer is a good tool for inspecting command line arguments: http://technet.microsoft.com/en-us/sysi ... 96653.aspx

[Mayhew]

Thanks. That is a very helpful tool!

The reason I was checking this is I'm looking into a crash with our Windows app when loading web pages with large images (>~20 megapixels). In that case we crash deep in libcef.dll in SkMallocPixelRef* SkMallocPixelRef::NewAllocate(). The library simply fails to allocate the memory. What is strange is that the Windows CefClient, built with the same CEF version (3.2062.1836) opens the pages fine and never crashes. I've tried using exactly the same browser and CEF settings as well as the same compiler options and preprocessor macros but I'm still seeing a crash. It's pretty strange.

[magreenblatt]

What is the overall allocation of memory by your application's processes? Perhaps you have a memory leak that is exhausting the address space.

[Mayhew]

With the test page loaded the first time, CefClient and our app are about the same. That is ~600,000K in the renderer, ~90,000K in the gpu and about ~30,000K in the main app. It is on the second load (i.e. reload) where mine crashes. CefClient never gets much above those initial amounts on subsequent loads. When my app crashes it is at about the same memory usage. it's not like it is getting much higher than that then crashing.

I am seeing [1027/152947:ERROR:ipc_channel_win.cc(409)] pipe error: 232 when I load the page in my app. Not sure where that is coming from.

[Mayhew]

One interesting note. If I set a breakpoint in my OnLoadStart() handler and simply continue execution when it is hit, the crash does not happen. If I remove the breakpoint and reload it crashes immediately. So the slight delay in OnLoadStart seems to make it work. Must be a timing issue.

[Mayhew]

Okay, the problem stems from exactly when the large SkMallocPixelRef object is freed or garbage collected. If it is freed prior to the allocation of the new one (on a page reload), then all is well. I'm surprised this doesn't happen in CefClient but it really does come down to a very specific timing issue. If I delay my browser process in one of callbacks like OnAddressChange or OnBeforeBrowse or OnLoadStart, then the garbage collection happens before the new, large allocation. Take the delay out and SkMallocPixelRef will fail to alloc as two of these 300+mb objects cannot exist in memory at once.

I'm not sure what the right solution is as the allocation/deallocation is over in the renderer process.

[magreenblatt]

Do you have control over the images? Perhaps you can scale them before display or change the image format to reduce the amount of memory required.

[Mayhew]

Yes I do because we are handling these in a resource handler. It is easy for me to substitute the image for a smaller one as a workaround.

Assuming this "could" come up in general pages with large images in cefclient, is it possible to force garbage collection prior to loading a page? Somehow Chrome never gets into this situation and if I force my browser process to wait in the debugger, garbage collection fires before the load anyway (on a timer I think).