Creating browser failed - race condition?

[Czarek]

Hi Marshall,

What could be the cause for a random failure of browser creation? I'm calling cef_browser_host_create_browser_sync(). It happened today once that the window was empty - looks like the creation of browser failed. I didn't check what was returned, whether the pointer was null, added this code just now, so I will now if it happens again. I couldn't reproduce the problem. Now I'm wondering what could go wrong. The code is like this:

Code: Select all

cef.Initialize(settings)

// Create GTK window.
gtk.Initialize()
window := gtk.CreateWindow("cef2go example", 1024, 768)

// Create browser.
url := "file://" + cwd + "/example.html"
cef.CreateBrowser(window, browserSettings, url)


When I compared logs with launches that were successful, the only thing that differed was that it was missing the "Running renderer without sandbox" error in the console. Normally when browser creation succeeds I always see this message, as no sandbox info is set.

I recall that in the cefsimple example, the browser is created in OnContextInitialized. And am wondering now whether it is guaranteed for the context to be initialized after CefInitialize() returns?

I am thinking on creating some stress test, to launch application for 1000 times and see if I can reproduce this.

Using branch 1750 revision 1604 on Ubuntu 64-bit.

Thanks for taking a look at this.

[magreenblatt]

Calling CefInitialize and then immediately calling CreateBrowserSync isn't a good idea -- there have been reports of miscellaneous problems with this approach on various platforms. Better to use either OnContextInitialized or CreateBrowser (without the sync).

[Czarek]

Calling CefInitialize and then immediately calling CreateBrowserSync isn't a good idea -- there have been reports of miscellaneous problems with this approach on various platforms. Better to use either OnContextInitialized or CreateBrowser (without the sync).

I've looked at the source code in context.cc: CefInitialize() calls CefContext::Initialize() which in turn calls OnContextInitialized(). So basically OnContextInitialized() is called before Initialize() returns. In a case when Initialize was called on UIT. So it looks like the real problem are the calls to CreateBrowserSync in general. So maybe we should remove this method completely from API, as it is unreliable?

[Czarek]

I've changed code and now I'm calling the asynchronous version. Unfortunately the problem still persists. Browser creation fails. But this time I don't see an empty window. When browser creation fails in CEF, then CEF sends a signal to destroy window. Thus cef_quit_message_loop() is called and application quits.

It happens about 1/40 launches of application. Observed on CEF 3 branch 1750 revision 1604 on Ubuntu 64-bit.

What can I do now?

[magreenblatt]

OnContextCreated isn't always called sychronously -- for example when using multi-threaded message loop on windows. I believe the problem-avoiding thing is to create the browser after the message loop has started. That's what the async version of CreateBrowser does. It's also safe to use the sync version provided the message loop has started (like from a UI thread callback somewhere else).

Your every 40th run problem is interesting. Sounds like a timing issue. Can you create a minimal program that reproduces it?

[Czarek]

Your every 40th run problem is interesting. Sounds like a timing issue. Can you create a minimal program that reproduces it?

Would it be okay to create an example in the CEF C API project? I would create a python script that launches app instances in a loop. It checks for the "###SUCCEEDED" message in the output. In onloadend this would be printed to the console. If it's missing then it means that browser creation failed. It would be built and launched using "make every40" command or something.

[magreenblatt]

Your every 40th run problem is interesting. Sounds like a timing issue. Can you create a minimal program that reproduces it?

Would it be okay to create an example in the CEF C API project? I would create a python script that launches app instances in a loop. It checks for the "###SUCCEEDED" message in the output. In onloadend this would be printed to the console. If it's missing then it means that browser creation failed. It would be built and launched using "make every40" command or something.

I'd prefer a patch against cefsimple since it's known to be stable and can be built/tested on all platforms.

[Czarek]

I'd prefer a patch against cefsimple since it's known to be stable and can be built/tested on all platforms.

Okay. Let's just hope that the bug is reproducible using C++ api. Issue 1198 shows that there may be bugs that show itself only when using C api, while C++ api works fine.

I noticed the bug in branch 1750. Should I create patch against it, or should I use trunk?

[magreenblatt]

I'd prefer a patch against cefsimple since it's known to be stable and can be built/tested on all platforms.

Okay. Let's just hope that the bug is reproducible using C++ api. Issue 1198 shows that there may be bugs that show itself only when using C api, while C++ api works fine.

All of the C API functions are exercised by the C++ code. Maybe there's some issue with the structure/type definitions in the C compile vs the C++ compile -- something wrong with structure packing and/or compile flags to match the Chromium build?

I noticed the bug in branch 1750. Should I create patch against it, or should I use trunk?

Either is fine.

[Czarek]

The same problem noticed on OSX, also branch 1750. Browser is created asynchronously and it fails every 10-20 launches, with no error message in the console.