Discovery of the "icudtl.dat" file fails on Linux. Merge patch into upstream.

[cztomczak]

Tried running pygtk_.py and wxpython.py both fail. Stack trace:

#0  0x00007ffff68e1035 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff68e479b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff180eab2 in base::debug::BreakDebugger() ()
   from /home/czarek/github/cefpython/src/linux/binaries_64bit/libcef.so
#3  0x00007ffff43ceeec in content::ContentMainRunnerImpl::Initialize(content::ContentMainParams const&) ()
   from /home/czarek/github/cefpython/src/linux/binaries_64bit/libcef.so
#4  0x00007ffff173a62f in CefContext::Initialize(CefMainArgs const&, CefStructBase<CefSettingsTraits> const&, CefRefPtr<CefApp>, void*) () from /home/czarek/github/cefpython/src/linux/binaries_64bit/libcef.so
#5  0x00007ffff173a48b in CefInitialize(CefMainArgs const&, CefStructBase<CefSettingsTraits> const&, CefRefPtr<CefApp>, void*) () from /home/czarek/github/cefpython/src/linux/binaries_64bit/libcef.so
#6  0x00007ffff16e7c88 in cef_initialize ()
   from /home/czarek/github/cefpython/src/linux/binaries_64bit/libcef.so
#7  0x00007fffe85b82b3 in CefInitialize(CefMainArgs const&, CefStructBase<CefSettingsTraits> const&, CefRefPtr<CefApp>, void*) () from /home/czarek/github/cefpython/src/linux/binaries_64bit/cefpython_py27.so
...

cefclient and cefsimple do run fine however. Looks like it might be an issue with CHECK failing because it can't find the "icudtl.dat" resource. If file "icudtl.dat" is removed then cefclient also fails with the same stack trace.

cefpython logs:

[CEF Python] Initialize() called
[CEF Python] CefExecuteProcess(): exitCode = -1
[CEF Python] CefInitialize()
[CEF Python] App_OnBeforeCommandLineProcessing_BrowserProcess()
[CEF Python] Command line string for the browser process:  --browser-subprocess-path=/home/czarek/github/cefpython/src/linux/binaries_64bit/subprocess --no-sandbox --lang=en-US --log-file=/home/czarek/github/cefpython/src/linux/binaries_64bit/debug.log --log-severity=info --resources-dir-path=/home/czarek/github/cefpython/src/linux/binaries_64bit --locales-dir-path=/home/czarek/github/cefpython/src/linux/binaries_64bit/locales --remote-debugging-port=50900

Program received signal SIGABRT, Aborted.

New error message, more descriptive in CEF 51:

[0626/190605:ERROR:icu_util.cc(183)] Invalid file descriptor to ICU data received.

[cztomczak]

Same error happens with CEF 51 and the message is more descriptive this time. It's definitely an issue with the icudtl.dat file. Reported with details on the CEF Forum:

http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=14271

[cztomczak]

Temporary fix for the issue:

sudo cp icudtl.dat /usr/bin
sudo cp natives_blob.bin /usr/bin

The pygtk_.py example runs fine with this fix.

[cztomczak]

Related code in Chromium that causes issues:

• In base/i18n/icu_util.cc: bool path_ok = PathService::Get(DIR_EXE, &data_path);
• In gin/v8_initializer: PathService::Get(base::DIR_EXE, &data_path); - to load "natives_blob.bin" which also causes issue

PathService keys like DIR_EXE, DIR_MODULE etc. can be overriden using PathService::Override, see base/path_service.h:
https://cs.chromium.org/chromium/src/base/path_service.h?cl=GROK&gsn=PathService&l=47

CEF already exposes CefGetPath() function to fetch paths using PathKey:
https://bitbucket.org/chromiumembedded/cef/src/05ee60b7b4704f5e763b65d2a1fbea83815b34ac/libcef/browser/path_util_impl.cc?at=master

Here are the values for some of the path keys when running cefpython:

[CEF Python] ---- PK_DIR_EXE: /usr/bin
[CEF Python] ---- PK_DIR_MODULE: /usr/bin
[CEF Python] ---- PK_DIR_CURRENT: /home/czarek/github/cefpython/src/linux/binaries_64bit
[CEF Python] ---- PK_FILE_EXE: /usr/bin/python2.7
[CEF Python] ---- PK_FILE_MODULE: /usr/bin/python2.7

When changing DIR_EXE we should probably also change DIR_MODULE to the same value. The question is what will be implications of overriding these paths. What would be better?
a) to create a patch for CEF to expose a new function CefOverridePath in path_util.impl.cc and then override DIR_EXE and DIR_MODULE paths before calling CefInitialize
b) or maybe just modify those two lines of code in Chromium and replace DIR_EXE with DIR_CURRENT

Note also the warning in path_service.h > Override:

// WARNING: Consumers of PathService::Get may expect paths to be constant
// over the lifetime of the app, so this method should be used with caution.

So when overriding path it should be done as early as possible.

In "chrome/test/base/chrome_test_suite.cc" there is already a case for overrriding DIR_EXE and DIR_MODULE, so it should work fine:

  if (!browser_dir_.empty()) {
    PathService::Override(base::DIR_EXE, browser_dir_);
    PathService::Override(base::DIR_MODULE, browser_dir_);
  }

[cztomczak]

Fixed in commit 2e9928d. New issue231 patch added to patches/.

[cztomczak]

Merge issue231 patch into upstream to allow for using Spotify binaries with cefpython. Pull request was already created some time ago with a reworked version of the patch that was to be accepted, but there was an issue with unit tests. The patch required another rework. See upstream Pull request #66 and upstream Issue #1936.

[cztomczak]

Alternative pull request for CEF on GitHub:
chromiumembedded/cef#4

[cztomczak]

Fixed in upstream in commit https://bitbucket.org/chromiumembedded/cef/commits/602c163 - needs testing.

[cztomczak]

Another related commit in upstream: https://bitbucket.org/chromiumembedded/cef/commits/942899d2fc3d

Both required commits are available in the latest 3945 branch (v79). This will allow to use Spotify binaries with cefpython on Linux.

[IoIxD]

Hi, I'm actually using CEF with C++ and I found this due to my own build error I'm having.

How did you end up solving this?

[cztomczak]

@IoIxD It was fixed via local patch. Upstream CEF also has this fixed. Make sure icudtl.dat is next to libcef.so.

[IoIxD]

I believe I found this out yes.

I also decided never to use CEF again, I really hope somebody makes a web browser that works better as a library.