[PyQt] 5.14 and macOS: Immediate renderer process crash with QtWebEngine

[Florian Bruhin]

Hey,

On Fri, Jan 03, 2020 at 12:11:01PM +0000, Colin McPhail wrote:
>   On 1 Jan 2020, at 18:21, Florian Bruhin <[1]me at the-compiler.org> wrote:
>   On Tue, Dec 31, 2019 at 07:42:01PM +0000, Phil Thompson wrote:
> 
>     On 31/12/2019 18:13, Florian Bruhin wrote:
> 
>       Hey,
> 
>       I just tried to upgrade to PyQt 5.14 on macOS, but a simple
>       QtWebEngine
>       application like this:
> 
>       [...]
> 
>       results in an immediate renderer process crash, making QtWebEngine
>       unusable.
> 
> ...
> 
>       I tried running with "--enable-logging --v=8
>       --enable-in-process-stack-traces"
>       in the hope of getting Chromium to print more, but no luck...
> 
>     There will be something from a Qt installation that is new in v5.14
>     that is
>     missing from the wheel.
> 
> ...
> 
>   At this point, I'm pretty much out of ideas... I tried running with
>   --single-process in the hope of getting a stacktrace, but to my
>   surprise, that
>   makes things work just fine. So I'm guessing it's indeed *something*
>   wrong
>   around QtWebEngineCore.framework or QtWebEngineProcess?
> 
>   Florian
> 
>   --
> 
> I too have noticed these render process crashes. I'm using the PyQt 5.14
> wheels and Python 3.8.1 from [2]python.org on macOS Catalina (10.15.2).
> Apple's Console utility app is showing me crash reports and I have
> attached one. I took a quick look at the source files it mentions and the
> renderer seems to be trying to locate a directory containing spelling
> checker dictionaries (?).

Oh, I wasn't aware it was possible to get crash information that way. So it
looks like it crashes here:

  CFBundleCopyBundleURL
    (inside macOS stuff)
  
  QLibraryInfo::location(QLibraryInfo::LibraryLocation) + 2258 (qlibraryinfo.cpp:542)
    CFBundleRef qtCoreBundle = CFBundleGetBundleWithIdentifier( CFSTR("org.qt-project.QtCore"));
    Q_ASSERT(qtCoreBundle);
    QCFType<CFURLRef> qtCorePath = CFBundleCopyBundleURL(qtCoreBundle);
  
  QLibraryInfo::location(QLibraryInfo::LibraryLocation) + 1305 (qlibraryinfo.cpp:831)
    (line number doesn't seem to make any sense)
  
  WebEngineLibraryInfo::getPath(int) + 3128 (web_engine_library_info.cpp:244)
    QString libraryDictionariesPath = QLibraryInfo::location(QLibraryInfo::DataPath)
       % QDir::separator() % QLatin1String("qtwebengine_dictionaries");
  
  QtWebEngineCore::ContentMainDelegateQt::BasicStartupComplete(int*) + 254 (string:912)
    (line number doesn't seem to make any sense)
  
  [...]

The docs for CFBundleGetBundleWithIdentifier say that it returns NULL if a
bundle wasn't found. So I'm guessing that's happening and the assertion isn't
triggered because it's a release build?

The docs say:

  For a bundle to be located using its identifier, the bundle must already have
  been loaded. [...]
  
  Bundle identifiers are created by entering a value for the key
  CFBundleIdentifier in the bundle’s Info.plist file.

The underlying code is new in Qt 5.14, to make Qt installation relocatable:
https://codereview.qt-project.org/c/qt/qtbase/+/210936
(The old code used CFBundleGetMainBundle() from what it seems)

So I'm guessing that is the culprit somehow? Maybe the QtCore bundle isn't
loaded from the point of view of QtWebEngineProcess? But then no idea why
that'd happen with PyQt but not Qt itself.

Florian

-- 
me at the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
       https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
       GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
             I love long mails! | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20200103/2a208a67/attachment.sig>