Re: 5.14 and macOS: Immediate renderer process crash with QtWebEngine

On 03/01/2020 21:56, Florian Bruhin wrote:
> Hey,
> 
> On Fri, Jan 03, 2020 at 12:11:01PM +0000, Colin McPhail wrote:
>>   On 1 Jan 2020, at 18:21, Florian Bruhin <[1][email protected]> 
>> 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.

Thanks, that was the clue I needed. The missing file is 
QtCore.framework/Resources/Info.plist

Phil
_______________________________________________
PyQt mailing list    [email protected]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt