search

e4x / cefpython

Automatically exported from code.google.com/p/cefpython
0 stars 0 forks source link

CefInitialize fails intermittently on Linux during launch of a subprocess #131

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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:
https://github.com/CzarekTomczak/cef2go/issues/8

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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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 6e60d785f4fb. 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 commented 9 years ago 
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 commented 9 years ago 
0.5 sec may not be enough in some scenarios, see:
https://github.com/paperlesspost/cef2go/commit/9926279ac27901ee88e6fc7ff5e4efaf5
ec73a36#commitcomment-7772958

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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
According to this comment by Aaron 
(https://github.com/paperlesspost/cef2go/commit/1ad2fc8340195174863916440cf76cdc
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 commented 9 years ago 
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