Details
-
Bug
-
Resolution: Done
-
P1: Critical
-
5.9.0 Beta 4
-
55a5420173b6ab10611eb91386b54217b8218ba0
Description
QtWebEngine asserts when an application calls, in that order
page.profile()->setHttpCacheType(QWebEngineProfile::MemoryHttpCache); page.profile()->setPersistentCookiesPolicy(QWebEngineProfile::NoPersistentCookies);
ASSERT: "m_updateHttpCache" in file /d/qt/5/kde/qtwebengine/src/core/url_request_context_getter_qt.cpp
It's a race condition (semantic race, not C++11 data race), so it doesn't happen 100% of the time, but still too often
The attached patch for qtwebengine/tests/auto/widgets/qwebengineprofile/tst_qwebengineprofile reproduces the issue. This appeared in Qt 5.9 (KMail was doing the same with 5.8 without hitting any assert).
Here's my debug output of what happens with that m_updateHttpCache boolean :
generateHttpCache: setting m_updateHttpCache to false updateHttpCache: m_updateAllStorage is false, setting m_updateHttpCache to true updateCookieStore: m_updateHttpCache set to true, calling generateCookieStore delayed generateHttpCache: setting m_updateHttpCache to false generateCookieStore: m_updateAllStorage is false, so m_updateHttpCache should be true: false ==> ASSERT!
Clearly, setting a bool and then checking it in another thread is not a valid programming practice, another call in the main thread can have changed that bool again meanwhile.
But I'm not sure how this should be fixed.