5.6 #3
Closed
5.6 #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Change-Id: I9ee9754d3464f0cf33718267535ba6d054bbea10
When converting the parameters of a C++ signal to JS values to provide to a signal handler written in JS, the conversion of a QJSValue to a QV4::Value* may yield a null pointer in case of a default constructed QJSValue for example. This is a regression from commit aa869cb and we must check for this. Task-number: QTBUG-58133 Change-Id: I528b606b2851dfb3072e54902bd8843d31571a55 Reviewed-by: Lars Knoll <lars.knoll@qt.io> (cherry picked from commit 0e3380f)
Private Use Area characters are quite valid input characters when used in combination with a custom font. Joiners also serve an important language purpose in semitic writing systems. [ChangeLog][QtWidgets][Input] Support characters in Private Use Area, as well as zero-width joiners and zero-width non-joiners in input in TextInput and TextEdit. Task-number: QTBUG-42074 Task-number: QTBUG-57003 Change-Id: I62bcd2ab0784f7f731921fbcdd8c695c02b165e4 (cherry picked from commit 97e4d5d) Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
After commit 0e3380f we wouldn't crash anymore, if QJSValue::UndefinedValue was provided as value for a QJSValue C++ signal parameter. However that was not a complete fix for the regression of commit aa869cb, as other primitive values stored in QJSValue as QVariant were not converted, so for example QJSValue(42). So let's fix this once and for all by using QJSValuePrivate::valueForData, that handles all types of QJSValuePrivate encodings. Task-number: QTBUG-58133 Change-Id: Ib7c0461b18df6260ccd4bce729ae2348281eb7f3 Reviewed-by: Arnaud Vrac <avrac@freebox.fr> Reviewed-by: Lars Knoll <lars.knoll@qt.io> (cherry picked from commit 89c6bee)
Change-Id: I88ffdd1d1224705e980e449b6c799c9f186143b1 Task-number: QTBUG-58271 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> (cherry picked from commit 22b03fd) Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
Transitions contain both an id and a set of flags, but the sorting failed to take the flags into account in the operator<. As a result we would some times end up with duplicate entries if the same id was added multiple times with different flags. If the same id was added again and again with varying flags, this could lead to an ever expanding list filled with duplicate entries. Fix this by also taking flags into account in operator< so that operator< and operator== are symetric and the list gets correctly sorted. Change-Id: I6d55c67083e4a09e3eb2952edbec302389421f33 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Robin Burchell <robin.burchell@crimson.no> (cherry picked from commit 94324a4)
Only 65536 vertices (65536 / 4 = 16384 characters) can be drawn in one draw call. This is why QSGDistanceFieldGlyphNode (renderType: Text.QtRendering) creates subnodes if number of characters exceeds that limit. QSGDefaultGlyphNode (renderType: Text.NativeRendering) missed that logic for some reason. Task-number: QTBUG-58852 Change-Id: I88b3fcdb8e56bc92622d3347cd638634d43df138 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io> (cherry picked from commit 42e098f)
GCC 7 warns about preprocessor macros expanding to defined(), which the masm config macros use pervasively. Fix by suppressing the warning (-Wexpansion-to-defined). Task-number: QTBUG-59647 Change-Id: I9220741cf594824472bffc2305b994b311e55832 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> (cherry picked from commit 29bf17d)
Don't define QML_PARSER_EXPORT to dllimport when doing static builds. Task-number: QTBUG-59767 Change-Id: I24acb2c51f54a0cde8d2e50a935ede876e5eb5b7 Reviewed-by: Andy Shaw <andy.shaw@qt.io> (cherry picked from commit 3caf24c)
This rarely happens - only seen with Delegates - when - an object is created during incubation - some error occurs in this object - the object gets deleted before the incubation run finishes Because the errors are delivered after the incubation run finished, the object() pointer of QQmlError is now a dangling pointer that will crash your application if accessed. Change-Id: Idd9fccbc58e4ada67bde3ca1aeec736aa9374789 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> (cherry picked from commit 6a8a7e6)
If an external QObject is exposed to an engine through a QObjectWrapper, make sure to deref and clear the propertyCache reference in the object's declarative data when the QObjectWrapper is destroyed. This makes sure that there is no dangling propertyCache pointer when the object is subsequently exposed to another engine. Task-number: QTBUG-57633 Change-Id: I37f6793d8be65b23b4e81bb4ed91db18271261b0 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> (cherry picked from commit 749a721)
Added a check that Batch::drawSets is not empty. Task-number: QTBUG-48439 Change-Id: Ica76363be8c770240dc69c669815a60904e26988 Reviewed-by: Gunnar Sletta <gunnar@sletta.org> (cherry picked from commit 893a4ff) Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io> Reviewed-by: Jason Erb (Suitable Technologies) <erb@suitabletech.com>
Now that the oterh QJSValue benchmark is fixed (yes, there were two benchmarks with the same name), this benchmark is superfluous. Change-Id: I39a7f9cc79dccef8aac3d4c3999a3d75e1b1aa3d Reviewed-by: Robin Burchell <robin.burchell@crimson.no> (cherry picked from commit 448104e)
The benchmark added the tst_QJSValue instance driving the benchmark to the engine, which then takes over ownership. This would result in a use-after-free, leading to a crash. Change-Id: I524445487a1dabb3fb3fbbfb7fca084f7736c124 Reviewed-by: Robin Burchell <robin.burchell@crimson.no> (cherry picked from commit 365d43a)
(cherry picked from commit 30dbe57) Change-Id: I20a030ddba6ae42b9959473fe68e622c6a42a8bf Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The various Q_GLOBAL_STATICs involved in the loading of debug plugins may be destroyed in any order. If the connector is unloaded before the services, it might get reloaded when one service calls instance(), trying to de-register itself. Prevent this by clearing all the parameters. Change-Id: If0df8e7086e7e2a4d8701f61addd8c4a661aa349 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> (cherry picked from commit fca6857)
The removed benchmarks don't make sense anymore: they were testing the QQmlEngine part, while another test was doing the QJSEngine. These days the QQmlEngine is a subclass of the QJSEngine and the test would call the QJSEngine (which, as said, was already done in another benchmark). Change-Id: Id1982dc118c399938a2dca8fb3c0a733e52fb20e Reviewed-by: Lars Knoll <lars.knoll@qt.io> (cherry picked from commit 9abcbbd)
Change-Id: Ifb1b6f6d71d42c1642167725526c054f1dce0c90 Reviewed-by: Robin Burchell <robin.burchell@crimson.no> (cherry picked from commit 9064d07)
They are broken. See QTBUG-60621 for details. Task-number: QTBUG-60621 Change-Id: Ibf55c64ef1b367bc2058d1c2284cd378ffa826ec Reviewed-by: Robin Burchell <robin.burchell@crimson.no> (cherry picked from commit 23a3018)
Again JS ownership, now shown as an attempt to free a non-malloced pointer. Change-Id: I00a9b1e4918da96aa5bc99a321edc94d76c4f45b Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> (cherry picked from commit 63f0406) Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
This was using symbols exported only by a developer build. Change-Id: If2e80a7f7831366a23c5c52669915385cfb3e7c6 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> (cherry picked from commit 720a88b) Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
QQuickWidget::grabFrameBuffer() was not polishing its items nor syncing the scene graph compared to standard QQuickWindow::grabWindow(). This lead to QQuickWidget grabbed content to be outdated (render the previous frame as a new frame). Task-number: QTBUG-57596 Change-Id: I0a2eff0c4f84cfd432f60f9d2fc41ac6a723fa5e Reviewed-by: Robin Burchell <robin.burchell@viroteck.net> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> (cherry picked from commit 0d243a8) Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
Ensure any error is deleted when the expression is Change-Id: Ibbfd28f50279d4c66830b40c5c917eb8d98f266e Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> (cherry picked from commit 1e06851)
The QtQuick designer support may override the meta-object and reparent the property-cache of the object under editing. The code for replacing the parent of the property cache however was not handling the refcount of the _parent correctly. Change-Id: Ic73294fc208b297e8ec9c0b775b5da01a309dba6 Reviewed-by: Robin Burchell <robin.burchell@viroteck.net> (cherry picked from commit 7dc5cd9) Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
Check d->_movie pointer before dereferencing Task-number: QTBUG-62380 Change-Id: I62314c7c0d4a7e41fa6f8c4629d16f30d6036156 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry-picked from fc3ecd2)
Task-number: QTBUG-56551 Change-Id: Ide09f177d3f6a3e9902f8ea904b3e6e4b998bd39 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> (cherry picked from commit 02830aa) Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
Crazy? pushing 5.6 changes to 5.9? |
|
i have no clue what this is supposed to be about, but anyway: http://wiki.qt.io/Qt_Contribution_Guidelines |
qtprojectorg
pushed a commit
that referenced
this pull request
Feb 15, 2018
When a QQuickWindow is a child of another QObject (such as a Loader) and
is scheduled for deletion using a deferred delete event, then a deletion
via the parent ends up calling the window's destructor, which will
finally end up in ~QObject(), which takes care of removing the posted
deferred deletion event from the event queue.
In the case of QQuickWindow, the destructor - called before ~QObject -
calls windowDestroyed(this) on the SG render loop. The implementation in
the software renderer calls QCoreApplication::sendPostedEvents() with
QEvent::DeferedDelete, which ends up deleting the same window a second
time and resulting in a crash.
I can't see a good reason for the existence of the sendPostedEvents()
call there. It is not present in the other render loops and according to
git blame it stems from the very early first implementation of the
software renderer where surely copy & paste from other render loop code
was involved back then.
The same fix is applied to the single-threaded VG and D3D12 render
loops, as they are most likely copy & paste from the software render
loop implementation.
ASAN trace for tst_qquickwindow::unloadSubWindow() on 5.11 branch that shows
invalid access to the QObjectPrivate/QQuickWindowPrivate, which follows the
QObject in terms of life-cycle:
==4736==ERROR: AddressSanitizer: heap-use-after-free on address 0x617000011778 at pc 0x7fdd211cfbb3 bp 0x7fffecb47ea0 sp 0x7fffecb47e90
READ of size 8 at 0x617000011778 thread T0
#0 0x7fdd211cfbb2 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1308
#1 0x7fdd21470974 in QQuickWindowQmlImpl::~QQuickWindowQmlImpl() items/qquickwindowmodule_p.h:63
#2 0x7fdd21470974 in QQmlPrivate::QQmlElement<QQuickWindowQmlImpl>::~QQmlElement() .../qqmlprivate.h:103
#3 0x7fdd21470974 in QQmlPrivate::QQmlElement<QQuickWindowQmlImpl>::~QQmlElement() .../qqmlprivate.h:103
#4 0x7fdd1e24da24 in qDeleteInEventHandler(QObject*) kernel/qobject.cpp:4601
#5 0x7fdd1e253d2f in QObject::event(QEvent*) kernel/qobject.cpp:1240
#6 0x7fdd1fbd1d41 in QWindow::event(QEvent*) kernel/qwindow.cpp:2356
#7 0x7fdd211f778e in QQuickWindow::event(QEvent*) items/qquickwindow.cpp:1628
#8 0x7fdd1e1a4e3c in QCoreApplicationPrivate::notify_helper(QObject*, QEvent*) kernel/qcoreapplication.cpp:1216
#9 0x7fdd1e1a508b in doNotify kernel/qcoreapplication.cpp:1157
#10 0x7fdd1e1a555a in QCoreApplication::notify(QObject*, QEvent*) kernel/qcoreapplication.cpp:1143
#11 0x7fdd1fb87665 in QGuiApplication::notify(QObject*, QEvent*) kernel/qguiapplication.cpp:1723
#12 0x7fdd1e1a52fa in QCoreApplication::notifyInternal2(QObject*, QEvent*) kernel/qcoreapplication.cpp:1067
#13 0x7fdd1e1b6ed2 in QCoreApplication::sendEvent(QObject*, QEvent*) ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
#14 0x7fdd1e1b6ed2 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) kernel/qcoreapplication.cpp:1764
#15 0x7fdd1e1b8cda in QCoreApplication::sendPostedEvents(QObject*, int) kernel/qcoreapplication.cpp:1618
#16 0x7fdd210cb034 in QSGSoftwareRenderLoop::windowDestroyed(QQuickWindow*) scenegraph/adaptations/software/qsgsoftwarerenderloop.cpp:100
#17 0x7fdd211cfb8c in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1305
[...]
0x617000011778 is located 632 bytes inside of 704-byte region [0x617000011500,0x6170000117c0)
freed by thread T0 here:
#0 0x7fdd21a8a9d8 in operator delete(void*, unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe19d8)
#1 0x7fdd2146fa3c in QQuickWindowQmlImplPrivate::~QQuickWindowQmlImplPrivate() items/qquickwindowmodule.cpp:57
#2 0x7fdd1e26b252 in QScopedPointerDeleter<QObjectData>::cleanup(QObjectData*) [...]
#3 0x7fdd1e26b252 in QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::~QScopedPointer() [...]
#4 0x7fdd1e26b252 in QObject::~QObject() kernel/qobject.cpp:882
#5 0x7fdd1fbcf51c in QWindow::~QWindow() kernel/qwindow.cpp:211
#6 0x7fdd211d0466 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1297
#7 0x7fdd211d0644 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1335
#8 0x7fdd1e2666b4 in QObjectPrivate::deleteChildren() kernel/qobject.cpp:1995
#9 0x7fdd1e26b329 in QObject::~QObject() kernel/qobject.cpp:1023
[...]
Change-Id: Iffa90d365d02b074e2a78c5be2895c9f86a4b80e
Task-number: QTBUG-66381
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
qtprojectorg
pushed a commit
that referenced
this pull request
Feb 15, 2018
When a QQuickWindow is a child of another QObject (such as a Loader) and
is scheduled for deletion using a deferred delete event, then a deletion
via the parent ends up calling the window's destructor, which will
finally end up in ~QObject(), which takes care of removing the posted
deferred deletion event from the event queue.
In the case of QQuickWindow, the destructor - called before ~QObject -
calls windowDestroyed(this) on the SG render loop. The implementation in
the software renderer calls QCoreApplication::sendPostedEvents() with
QEvent::DeferedDelete, which ends up deleting the same window a second
time and resulting in a crash.
I can't see a good reason for the existence of the sendPostedEvents()
call there. It is not present in the other render loops and according to
git blame it stems from the very early first implementation of the
software renderer where surely copy & paste from other render loop code
was involved back then.
The same fix is applied to the single-threaded VG and D3D12 render
loops, as they are most likely copy & paste from the software render
loop implementation.
ASAN trace for tst_qquickwindow::unloadSubWindow() on 5.11 branch that shows
invalid access to the QObjectPrivate/QQuickWindowPrivate, which follows the
QObject in terms of life-cycle:
==4736==ERROR: AddressSanitizer: heap-use-after-free on address 0x617000011778 at pc 0x7fdd211cfbb3 bp 0x7fffecb47ea0 sp 0x7fffecb47e90
READ of size 8 at 0x617000011778 thread T0
#0 0x7fdd211cfbb2 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1308
#1 0x7fdd21470974 in QQuickWindowQmlImpl::~QQuickWindowQmlImpl() items/qquickwindowmodule_p.h:63
#2 0x7fdd21470974 in QQmlPrivate::QQmlElement<QQuickWindowQmlImpl>::~QQmlElement() .../qqmlprivate.h:103
#3 0x7fdd21470974 in QQmlPrivate::QQmlElement<QQuickWindowQmlImpl>::~QQmlElement() .../qqmlprivate.h:103
#4 0x7fdd1e24da24 in qDeleteInEventHandler(QObject*) kernel/qobject.cpp:4601
#5 0x7fdd1e253d2f in QObject::event(QEvent*) kernel/qobject.cpp:1240
#6 0x7fdd1fbd1d41 in QWindow::event(QEvent*) kernel/qwindow.cpp:2356
#7 0x7fdd211f778e in QQuickWindow::event(QEvent*) items/qquickwindow.cpp:1628
#8 0x7fdd1e1a4e3c in QCoreApplicationPrivate::notify_helper(QObject*, QEvent*) kernel/qcoreapplication.cpp:1216
#9 0x7fdd1e1a508b in doNotify kernel/qcoreapplication.cpp:1157
#10 0x7fdd1e1a555a in QCoreApplication::notify(QObject*, QEvent*) kernel/qcoreapplication.cpp:1143
#11 0x7fdd1fb87665 in QGuiApplication::notify(QObject*, QEvent*) kernel/qguiapplication.cpp:1723
#12 0x7fdd1e1a52fa in QCoreApplication::notifyInternal2(QObject*, QEvent*) kernel/qcoreapplication.cpp:1067
#13 0x7fdd1e1b6ed2 in QCoreApplication::sendEvent(QObject*, QEvent*) ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
#14 0x7fdd1e1b6ed2 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) kernel/qcoreapplication.cpp:1764
#15 0x7fdd1e1b8cda in QCoreApplication::sendPostedEvents(QObject*, int) kernel/qcoreapplication.cpp:1618
#16 0x7fdd210cb034 in QSGSoftwareRenderLoop::windowDestroyed(QQuickWindow*) scenegraph/adaptations/software/qsgsoftwarerenderloop.cpp:100
#17 0x7fdd211cfb8c in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1305
[...]
0x617000011778 is located 632 bytes inside of 704-byte region [0x617000011500,0x6170000117c0)
freed by thread T0 here:
#0 0x7fdd21a8a9d8 in operator delete(void*, unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe19d8)
#1 0x7fdd2146fa3c in QQuickWindowQmlImplPrivate::~QQuickWindowQmlImplPrivate() items/qquickwindowmodule.cpp:57
#2 0x7fdd1e26b252 in QScopedPointerDeleter<QObjectData>::cleanup(QObjectData*) [...]
#3 0x7fdd1e26b252 in QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::~QScopedPointer() [...]
#4 0x7fdd1e26b252 in QObject::~QObject() kernel/qobject.cpp:882
#5 0x7fdd1fbcf51c in QWindow::~QWindow() kernel/qwindow.cpp:211
#6 0x7fdd211d0466 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1297
#7 0x7fdd211d0644 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1335
#8 0x7fdd1e2666b4 in QObjectPrivate::deleteChildren() kernel/qobject.cpp:1995
#9 0x7fdd1e26b329 in QObject::~QObject() kernel/qobject.cpp:1023
[...]
Change-Id: Iffa90d365d02b074e2a78c5be2895c9f86a4b80e
Task-number: QTBUG-66381
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit 238cc09)
qtprojectorg
pushed a commit
that referenced
this pull request
Nov 2, 2018
The signature is based on [1] and [2], with an empty implementation to match the default behavior. This mutes the following warning when building with MSVC 2015 & 2017: warning: C4291: 'void *operator new(::size_t,void *) throw()': no matching operator delete found; memory will not be freed if initialization throws an exception [1] https://en.cppreference.com/w/cpp/memory/new/operator_delete (#13) [2] http://www.cplusplus.com/reference/new/operator%20delete/ (#3) Task-number: QTBUG-71024 Change-Id: I32f80a902672d9af27960a185a1b0c91798806c5 Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
qtprojectorg
pushed a commit
that referenced
this pull request
Apr 25, 2019
Fix crash when QQmlMetaType::freeUnusedTypesAndCaches() is being called
during program exit, i.e. when the parent QJSEngine instance is being
destructed during exit().
Sample backtrace:
#0 QQmlMetaType::freeUnusedTypesAndCaches () at /home/kfunk/devel/src/qt5.12/qtdeclarative/src/qml/qml/qqmlmetatype.cpp:2600
#1 0x00007fffe12fce83 in QJSEnginePrivate::~QJSEnginePrivate (this=0x60c001c0b040, __in_chrg=<optimized out>) at /home/kfunk/devel/src/qt5.12/qtdeclarative/src/qml/jsapi/qjsengine.cpp:982
#2 0x00007fffe12fce9f in QJSEnginePrivate::~QJSEnginePrivate (this=0x60c001c0b040, __in_chrg=<optimized out>) at /home/kfunk/devel/src/qt5.12/qtdeclarative/src/qml/jsapi/qjsengine.cpp:980
#3 0x00007ffff53650c3 in QScopedPointerDeleter<QObjectData>::cleanup (pointer=<optimized out>) at ../../include/QtCore/../../../../../src/qt5.12/qtbase/src/corelib/tools/qscopedpointer.h:52
#4 QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::~QScopedPointer (this=0x60300178b3a8, __in_chrg=<optimized out>) at ../../include/QtCore/../../../../../src/qt5.12/qtbase/src/corelib/tools/qscopedpointer.h:107
#5 QObject::~QObject (this=<optimized out>, __in_chrg=<optimized out>) at /home/kfunk/devel/src/qt5.12/qtbase/src/corelib/kernel/qobject.cpp:891
#6 0x00007fffe12ff572 in QJSEngine::~QJSEngine (this=0x60300178b3a0, __in_chrg=<optimized out>) at /home/kfunk/devel/src/qt5.12/qtdeclarative/src/qml/jsapi/qjsengine.cpp:379
#7 0x00007fffe12ff583 in QJSEngine::~QJSEngine (this=0x60300178b3a0, __in_chrg=<optimized out>) at /home/kfunk/devel/src/qt5.12/qtdeclarative/src/qml/jsapi/qjsengine.cpp:375
#8 0x00007ffff5363cc4 in QObjectPrivate::deleteChildren (this=this@entry=0x60b00016c380) at /home/kfunk/devel/src/qt5.12/qtbase/src/corelib/kernel/qobject.cpp:2010
#9 0x00007ffff53650f5 in QObject::~QObject (this=<optimized out>, __in_chrg=<optimized out>) at /home/kfunk/devel/src/qt5.12/qtbase/src/corelib/kernel/qobject.cpp:1032
#10 0x00007fffe103b43b in Grantlee::ScriptableTagLibrary::~ScriptableTagLibrary (this=0x607000ba4c00) at templates/lib/Grantlee_Templates_autogen/MTDBPGIEEV/../../../../../../../src/kf5/grantlee/templates/scriptabletags/scriptabletags.h:58
#11 0x00007fffe103b469 in Grantlee::ScriptableTagLibrary::~ScriptableTagLibrary (this=0x607000ba4c00) at templates/lib/Grantlee_Templates_autogen/MTDBPGIEEV/../../../../../../../src/kf5/grantlee/templates/scriptabletags/scriptabletags.h:58
#12 0x00007ffff5363cc4 in QObjectPrivate::deleteChildren (this=this@entry=0x60b00016c0c0) at /home/kfunk/devel/src/qt5.12/qtbase/src/corelib/kernel/qobject.cpp:2010
#13 0x00007ffff53650f5 in QObject::~QObject (this=<optimized out>, __in_chrg=<optimized out>) at /home/kfunk/devel/src/qt5.12/qtbase/src/corelib/kernel/qobject.cpp:1032
#14 0x00007fffe0fef704 in Grantlee::Engine::~Engine (this=0x60300178a2c0) at /home/kfunk/devel/src/kf5/grantlee/templates/lib/engine.cpp:60
#15 0x00007fffdf2e2482 in GrantleeTheme::Engine::~Engine (this=0x60300178a2c0) at /home/kfunk/devel/src/kf5/grantleetheme/src/grantleethemeengine.cpp:54
#16 0x00007fffdf2e24a9 in GrantleeTheme::Engine::~Engine (this=0x60300178a2c0) at /home/kfunk/devel/src/kf5/grantleetheme/src/grantleethemeengine.cpp:52
#17 0x00007ffff3f4f8d1 in MessageViewer::MessagePartRendererManager::~MessagePartRendererManager (this=0x7ffff40c8ab0 <MessageViewer::MessagePartRendererManager::self()::s_self>) at /home/kfunk/devel/src/kf5/messagelib/messageviewer/src/messagepartthemes/default
/messagepartrenderermanager.cpp:118
#18 0x00007ffff4b442ac in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#19 0x00007ffff4b443da in exit () from /lib/x86_64-linux-gnu/libc.so.6
Also see:
https://bugs.kde.org/show_bug.cgi?id=406871
Change-Id: If5676880c87f1fa2405701a439e1a0037dce045c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
qtprojectorg
pushed a commit
that referenced
this pull request
Apr 8, 2022
We had multiple related issues due to application fonts being added or removed during the application lifetime. 1. If a text had font family "foo" set, and this font did not exist at the time, then loading "foo" at a later stage would not update the text to use the correct font, since the result of the previous request had been cached. 2. A variation of #1 was if the font "foo" was loaded by a FontLoader in the scene and referred to by name in the text component. In this case, there was a race condition, where the font lookup would sometimes yield different results on the main thread and on the render thread, and text would be garbled. 3. When a font was removed from the font database, then references to it would remain in the caches (glyph cache + font cache) in the render thread. With certain backends (DirectWrite, CoreText) this caused errors or even crashes, as the cached font engines would be referring to data that had been removed. The work-around for #1 and #2 was merely to avoid hardcoding names for fonts, but instead getting them from the FontLoader. This way, you can avoid requesting the font family before it is available (and thus avoid caching the wrong result). However, for #3 there is no known work-around. This patch fixes all three (together with a smaller patch for qtbase) by invalidating all text and related caches in Qt Quick when fonts are either added or removed from the font database. This does add some overhead if font loading happens during runtime, but the alternative is broken behavior and dangling pointers. This is done during the synchronization step. Before synchronization, the font cache is flushed and all text components are marked for update, so that fonts are re-requested against the new font database. After synchronization, we delete all distance field glyph caches which are not currently in use, to avoid having references to stale application font data in the list. [ChangeLog][Text] Fix multiple issues with usage of application fonts when they are added or removed during the lifetime of the application. Task-number: QTBUG-100697 Task-number: QDS-1142 Change-Id: Ib309e54e0ee97b6be6d2a7211964043fd51c9ec5 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
qtprojectorg
pushed a commit
that referenced
this pull request
Dec 8, 2023
Using std::binary_search has the requirement that the passed
range fulfils ordering requirements, which was not the case
for the cppKeywords array here.
As the QString doc says [1]:
> QStrings can be compared using overloaded operators such as operator<(),
> operator<=(), operator==(), operator>=(), and so on. Note that
> the comparison is based exclusively on the numeric Unicode
> values of the characters. It is very fast, but is not what a
> human would expect; (...)
Therefore, sort the array accordingly and add an assert to
ensure it will remain sorted.
Fixes an crash/assert when building qtdeclarative with
CXXFLAGS='-D_GLIBCXX_DEBUG':
/usr/include/c++/13/bits/stl_algo.h:2243:
In function:
bool std::binary_search(_FIter, _FIter, const _Tp&) [with _FIter = const
QString*; _Tp = QStringView]
Error: elements in iterator range [first, last) are not partitioned by the
value __val.
Objects involved in the operation:
iterator "first" @ 0x7ffc4a2c4f18 {
type = QString const* (constant iterator);
}
iterator "last" @ 0x7ffc4a2c4f10 {
type = QString const* (constant iterator);
}
Aborted (core dumped)
ninja: build stopped: subcommand failed.
GDB backtrace:
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1 0x00007f307e0a815f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 0x00007f307e05a472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007f307e0444b2 in __GI_abort () at ./stdlib/abort.c:79
#4 0x00007f307e2a300d in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00005639ff90471d in std::binary_search<QString const*, QStringView> (__first=0x5639ffa1a9c0 <QmltcVisitor::checkForNamingCollisionsWithCpp(QDeferredSharedPointer<QQmlJSScope const> const&)::cppKeywords>,
__last=0x5639ffa1b2c0 <guard variable for QmltcVisitor::checkForNamingCollisionsWithCpp(QDeferredSharedPointer<QQmlJSScope const> const&)::cppKeywords>, __val=...) at /usr/include/c++/13/bits/stl_algo.h:2243
#6 0x00005639ff8fb837 in operator() (__closure=0x7ffc4a2c52bf, word=...) at /home/michi/development/git/qt5/qtdeclarative/tools/qmltc/qmltcvisitor.cpp:764
#7 0x00005639ff8fb89e in operator() (__closure=0x7ffc4a2c52a0, name=..., errorPrefix=...) at /home/michi/development/git/qt5/qtdeclarative/tools/qmltc/qmltcvisitor.cpp:768
#8 0x00005639ff8fc99b in QmltcVisitor::checkForNamingCollisionsWithCpp (this=0x7ffc4a2c6070, type=...) at /home/michi/development/git/qt5/qtdeclarative/tools/qmltc/qmltcvisitor.cpp:787
#9 0x00005639ff8f9dea in QmltcVisitor::endVisit (this=0x7ffc4a2c6070, program=0x563a002e0628) at /home/michi/development/git/qt5/qtdeclarative/tools/qmltc/qmltcvisitor.cpp:341
#10 0x00007f307f6636fa in QQmlJS::AST::UiProgram::accept0 (this=0x563a002e0628, visitor=0x7ffc4a2c6070) at /home/michi/development/git/qt5/qtdeclarative/src/qml/parser/qqmljsast.cpp:1193
#11 0x00007f3080159b8f in QQmlJS::AST::Node::accept (this=0x563a002e0628, visitor=0x7ffc4a2c6070)
at /home/michi/development/git/qt5/qtbase/include/QtQml/6.7.0/QtQml/private/../../../../../../qtdeclarative/src/qml/parser/qqmljsast_p.h:272
#12 0x00007f3080212f4b in QQmlJSTypeResolver::init (this=0x7ffc4a2c5b50, visitor=0x7ffc4a2c6070, program=0x563a002e0628) at /home/michi/development/git/qt5/qtdeclarative/src/qmlcompiler/qqmljstyperesolver.cpp:173
#13 0x00005639ff8f0bd3 in QmltcTypeResolver::init (this=0x7ffc4a2c5b50, visitor=0x7ffc4a2c6070, program=0x563a002e0628) at /home/michi/development/git/qt5/qtdeclarative/tools/qmltc/qmltctyperesolver.cpp:19
#14 0x00005639ff8c02d4 in main (argc=23, argv=0x7ffc4a2c7a68) at /home/michi/development/git/qt5/qtdeclarative/tools/qmltc/main.cpp:269
[1] https://doc.qt.io/qt-6/qstring.html#comparing-strings
Change-Id: I82ebbcdca4ab90155b935f9af24b3a3821134563
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
qtprojectorg
pushed a commit
that referenced
this pull request
Dec 8, 2023
The Compare requirements [1] say:
> The return value of the function call operation applied to an object of
> a type satisfying Compare, when contextually converted to bool, yields
> true if the first argument of the call appears before the second in the
> strict weak ordering relation induced by this type, and false otherwise.
That requirement was violated here, because passing
the same value for both arguments would return true,
since the
inlineComponentB->inherits(inlineComponentA)
check returns true when both inline components
are the same.
Add an equality check to fix that.
Fixes a build failure when building with
CXXFLAGS='-D_GLIBCXX_DEBUG':
/usr/include/c++/13/bits/stl_algo.h:4892:
In function:
void std::sort(_RAIter, _RAIter, _Compare) [with _RAIter =
QList<variant<QString, monostate> >::iterator; _Compare =
QmltcCompiler::compile(const QmltcCompilerInfo&)::<lambda(const
QmltcCompiler::InlineComponentOrDocumentRootName&, const
QmltcCompiler::InlineComponentOrDocumentRootName&)>]
Error: comparison doesn't meet irreflexive requirements, assert(!(a < a)).
Objects involved in the operation:
instance "functor" @ 0x7ffec14329f8 {
type = QmltcCompiler::compile(QmltcCompilerInfo const&)::{lambda(std::variant<QString, std::monostate> const&, std::variant<QString, std::monostate> const&)#1};
}
iterator::value_type "ordered type" {
type = std::variant<QString, std::monostate>;
}
Aborted (core dumped)
ninja: build stopped: subcommand failed.
GDB backtrace:
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1 0x00007fbe6b4a815f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 0x00007fbe6b45a472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007fbe6b4444b2 in __GI_abort () at ./stdlib/abort.c:79
#4 0x00007fbe6b6a300d in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x0000560ae899bec4 in std::sort<QList<std::variant<QString, std::monostate> >::iterator, QmltcCompiler::compile(const QmltcCompilerInfo&)::<lambda(const QmltcCompiler::InlineComponentOrDocumentRootName&, const QmltcCompiler::InlineComponentOrDocumentRootName&)> >(QList<std::variant<QString, std::monostate> >::iterator, QList<std::variant<QString, std::monostate> >::iterator, struct {...}) (__first=..., __last=..., __comp=...)
at /usr/include/c++/13/bits/stl_algo.h:4892
#6 0x0000560ae898bd67 in QmltcCompiler::compile (this=0x7ffec1432e80, info=...) at /home/michi/development/git/qt5/qtdeclarative/tools/qmltc/qmltccompiler.cpp:85
#7 0x0000560ae89264b6 in main (argc=23, argv=0x7ffec1434fc8) at /home/michi/development/git/qt5/qtdeclarative/tools/qmltc/main.cpp:284
[1] https://en.cppreference.com/w/cpp/named_req/Compare
Change-Id: Ie8934b8381ef217c1f8860ee110f6fa2aa0c86fa
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.