Quick items: contiguous same update request #1
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
luocs
commented
Sep 20, 2016
luocs
commented
- Update request always send after addToDirtyList() called.
- It's more clear that we just do 'add' operation in addToDirtyList()
1. Update request always send after addToDirtyList() called. 2. It's more clear that we just do 'add' operation in addToDirtyList()
qtprojectorg
pushed a commit
that referenced
this pull request
Jul 27, 2017
CID 54558 (#1 of 1): Not restoring ostream format (STREAM_FORMAT_STATE) 4. end_of_path: Changing format state of stream d for category basefield without later restoring it. Coverity-Id: 54558 Change-Id: Iad6e6103684c57d3ab98e78e7c91e23731632913 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
qtprojectorg
pushed a commit
that referenced
this pull request
Feb 7, 2018
CID 186959 (#1 of 1): Macro compares unsigned to 0 (NO_EFFECT) unsigned_compare: This greater-than-or-equal-to-zero comparison of an unsigned value is always true. rev >= 0. CID 186960 (#2 of 2): Operands don't affect result (CONSTANT_EXPRESSION_RESULT) result_independent_of_operands: rev <= 255 /* std::numeric_limits<unsigned char>::max() */ is always true regardless of the values of its operands. This occurs as the logical first operand of ?:. Coverity-Id: 186959 Coverity-Id: 186960 Change-Id: Iaadadb89de1c8732b2756da8fda397632b6b7d93 Reviewed-by: Thomas Hartmann <thomas.hartmann@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>
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
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
Jun 15, 2020
Preprocessing in the scene graph is actually pretty expensive, so we want to avoid using it for something like text, where you can often have a lot of nodes in a UI. For text it was previously used for two purposes: 1. To make sure the distance field glyph cache was updated with potential new glyphs before the frame was rendered, but *after* all new glyph nodes had been created (this is an optimization to avoid having to resize the cache multiple times in one frame, but rather wait until we know the exact amount of new glyphs that need to be added) 2. Update the coordinates of the glyph based on their position in the glyph cache if the glyph cache says they have moved (or if they have just been added for the first time). Point #1 can actually be handled a lot simpler, by having a separate loop for the existing glyph caches where we ask them to preprocess. There is typically only a few glyph caches, but can be hundreds of glyph nodes in a scene, so in the previous code we would be calling the update() functions on the same glyph cache over and over again every frame. Point #2 does not need preprocessing every frame, but can be reduced to only preprocess when the geometry is marked as dirty. We then do a pass on the glyph node in question to update its geometry and turn the flag off again so that we don't pay the cost every frame. Pick-to: 5.15 Fixes: QTBUG-84351 Change-Id: If8c492acaef9c512c2db61b64bcab2103db2d997 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
qtprojectorg
pushed a commit
that referenced
this pull request
Jun 15, 2020
Preprocessing in the scene graph is actually pretty expensive, so we want to avoid using it for something like text, where you can often have a lot of nodes in a UI. For text it was previously used for two purposes: 1. To make sure the distance field glyph cache was updated with potential new glyphs before the frame was rendered, but *after* all new glyph nodes had been created (this is an optimization to avoid having to resize the cache multiple times in one frame, but rather wait until we know the exact amount of new glyphs that need to be added) 2. Update the coordinates of the glyph based on their position in the glyph cache if the glyph cache says they have moved (or if they have just been added for the first time). Point #1 can actually be handled a lot simpler, by having a separate loop for the existing glyph caches where we ask them to preprocess. There is typically only a few glyph caches, but can be hundreds of glyph nodes in a scene, so in the previous code we would be calling the update() functions on the same glyph cache over and over again every frame. Point #2 does not need preprocessing every frame, but can be reduced to only preprocess when the geometry is marked as dirty. We then do a pass on the glyph node in question to update its geometry and turn the flag off again so that we don't pay the cost every frame. Fixes: QTBUG-84351 Change-Id: If8c492acaef9c512c2db61b64bcab2103db2d997 Reviewed-by: Lars Knoll <lars.knoll@qt.io> (cherry picked from commit 1f3dd3f) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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>
qtprojectorg
pushed a commit
that referenced
this pull request
Feb 2, 2024
Every time type is compared and compare() is called, viewCount() must also be compared. More importantly, the correct view count (handled via internal flags for SC/BC) has to be pushed to the QSGMaterial always, before checking for an existing QSGMaterialShader - otherwise if material #2 has a hit for a shader from material #1, material #2 will never have the view count pushed so it continues to report viewCount() == 1, which has...interesting consequences. Avoid this. Change-Id: I0808cc57f53a8dab891d1b36b41790f58c978ef4 Reviewed-by: Andy Nichols <andy.nichols@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.