CefInitialize fails intermittently on Linux during launch of a subprocess

[GoogleCodeExporter]

Observed in branch 1650 when running the wx.chromectrl sample2.py example.
Reported here:
http://www.magpcss.org/ceforum/viewtopic.php?p=22227#p22227

It might be an edge case, as there is something wrong with the sample2.py
example. The wx controls eat 100% CPU all the time. The crash wasn't yet
observed in any of the other examples.

There is an issue in the CEF Issue Tracker for stress testing application
launching to detech and fix such problems:
https://code.google.com/p/chromiumembedded/issues/detail?id=1207

Similar problem occured in CEF2go on Linux and OSX:
cztomczak/cef2go#8

Original issue reported on code.google.com by czarek.t...@gmail.com on 1 Aug 2014 at 2:38

[GoogleCodeExporter]

CEF initialization failures can be resolved by offloading CPU after
Initialize() was called. CEF is still running some stuff in its thread after
Initialize returned, such as launching GPU process. If application is under
heave load during that initialization, it results in some race condition in CEF
that ends with segmentation fault. The solution is to sleep python script for
half a second after Initialize. See the code:

  cefpython.Initialize()
  if platform.system() == "Linux":
      import time
      time.sleep(0.5)

Stress test for launching app was commited in revision 6e60d78. About 5000
app launches were performed in total, under heavy load while running various
applications. It didn't fail not even once. When sleep was removed I was able
to reproduce segmentation fault multiple times, on average in about 100 runs.

Other CEF examples (wxpython, pygtk) should be updated with the sleep code on
Linux along with a comment that explains the issue.

Original comment by czarek.t...@gmail.com on 25 Aug 2014 at 12:17

[GoogleCodeExporter]

A corresponding issue in CEF tracker:
https://code.google.com/p/chromiumembedded/issues/detail?id=1362

Original comment by czarek.t...@gmail.com on 29 Aug 2014 at 5:25

[GoogleCodeExporter]

0.5 sec may not be enough in some scenarios, see:
paperlesspost/cef2go@9926279
ec73a36#commitcomment-7772958

Original comment by czarek.t...@gmail.com on 13 Sep 2014 at 2:40

[GoogleCodeExporter]

It might be worth trying to pass the --disable-gpu and --disable-gpu-sandbox
flags. The race condition occurs when launching the GPU process, so if we
disable launching the gpu process, maybe the issue will disappear. In newer CEF
versions the GPU process is always launched even with hardware acceleration
disabled. Not sure what is the status for our current branch 1650. Needs
testing.

Original comment by czarek.t...@gmail.com on 6 Jan 2015 at 8:40

[GoogleCodeExporter]

According to this comment by Aaron
(paperlesspost/cef2go@1ad2fc8
fbd59ce5#commitcomment-9446543), the crash occurs in the zygote process. It
might be worth trying to pass the --renderer-cmd-prefix flag which will result
in the zygote process not being launched. Found about this flag here:
https://code.google.com/p/chromium/wiki/LinuxZygote .

Original comment by czarek.t...@gmail.com on 26 Jan 2015 at 8:09

[GoogleCodeExporter]

There are two things that can be done now in regards to this issue:

1. Test it with newer branches: 1916 or later. So far it was confirmed that
   this issue occurs in branches 1650 and 1750. We still don't know if this is a
   CEF issue or a Chrome issue. Maybe it was fixed in later Chrome releases.

2. Get stack trace with meaningful symbols. Currently the stack trace provided
   in the CEF Issue 1362
   (https://code.google.com/p/chromiumembedded/issues/detail?id=1362) doesn't
   include any CEF/Chromium symbols. I was using the Release configuration when
   debugging it. Looks like the stack trace needs to be debugged using the Debug
   configuration.

Original comment by czarek.t...@gmail.com on 12 Feb 2015 at 3:20

[cztomczak]

Check if this is still an issue after update to Chrome 47.

[cztomczak]

I haven't noticed this issue anymore with CEF Python 51/53.