Skip to content

dynamically allocate model in ResultsTree#7798

Merged
firewave merged 1 commit intodanmar:mainfrom
firewave:resultstree-crash
Oct 2, 2025
Merged

dynamically allocate model in ResultsTree#7798
firewave merged 1 commit intodanmar:mainfrom
firewave:resultstree-crash

Conversation

@firewave
Copy link
Copy Markdown
Collaborator

@firewave firewave commented Sep 5, 2025

No description provided.

@firewave
Copy link
Copy Markdown
Collaborator Author

firewave commented Sep 5, 2025

QTreeView::setModel() takes a pointer, so given the usual Qt pattern this will surely take ownership of the object. So when ResultTree is being destroyed the model would be destroyed by the owner and RAII - if the previous assumption is correct.

Unfortunately this does not fix other crashing issues related to the results.

@firewave
Copy link
Copy Markdown
Collaborator Author

firewave commented Sep 5, 2025

Okay, now that test leaks memory. So it seems the tree won't take the ownership.

@firewave firewave marked this pull request as draft September 5, 2025 15:57
@firewave
Copy link
Copy Markdown
Collaborator Author

firewave commented Sep 5, 2025

Something is wrong with a QVariant object. If you call clearData() before the problematic setData() calls you get a segmentation fault with a local object.

@firewave
Copy link
Copy Markdown
Collaborator Author

firewave commented Sep 6, 2025

I pushed the minimized reproducer so it can be reproduced easily.

@firewave
Copy link
Copy Markdown
Collaborator Author

firewave commented Sep 6, 2025

It will only fail with GCC so since the ASAN job uses Clang it will always pass.

@firewave
Copy link
Copy Markdown
Collaborator Author

firewave commented Sep 6, 2025

It looks like the data passed to setData() is being accessed by reference and going out of scope destroys it. Nothing it noted about this in the documentation. Making that variable static makes it work. But then it should be showing issues with either compiler.

@firewave firewave force-pushed the resultstree-crash branch 3 times, most recently from 41c681d to ca53b38 Compare September 6, 2025 16:17
@firewave
Copy link
Copy Markdown
Collaborator Author

firewave commented Sep 6, 2025

I forgot to pass --track-origins=yes option to valgrind. Now I get this:

==26739== Use of uninitialised value of size 8
==26739==    at 0x5B4F527: QtPrivate::QMetaTypeForType<QMap<QString, QVariant> >::getDtor()::{lambda(QtPrivate::QMetaTypeInterface const*, void*)#1}::_FUN(QtPrivate::QMetaTypeInterface const*, void*) (in /usr/lib/libQt6Core.so.6.9.1)
==26739==    by 0x5B8E595: QVariant::operator=(QVariant const&) (in /usr/lib/libQt6Core.so.6.9.1)
==26739==    by 0x55D67B4: QStandardItem::setData(QVariant const&, int) (in /usr/lib/libQt6Gui.so.6.9.1)
==26739==    by 0x4007422: TestResultsTree::test1() const (testresultstree.cpp:30)
==26739==    by 0x40046FF: TestResultsTree::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_testresultstree.cpp:72)
==26739==    by 0x5B2E19A: QMetaMethodInvoker::invokeImpl(QMetaMethod, void*, Qt::ConnectionType, long long, void const* const*, char const* const*, QtPrivate::QMetaTypeInterface const* const*) (in /usr/lib/libQt6Core.so.6.9.1)
==26739==    by 0x5B2EA3E: QMetaMethod::invokeImpl(QMetaMethod, void*, Qt::ConnectionType, long long, void const* const*, char const* const*, QtPrivate::QMetaTypeInterface const* const*) (in /usr/lib/libQt6Core.so.6.9.1)
==26739==    by 0x50187AE: ??? (in /usr/lib/libQt6Test.so.6.9.1)
==26739==    by 0x501BA81: ??? (in /usr/lib/libQt6Test.so.6.9.1)
==26739==    by 0x502916F: QTest::qRun() (in /usr/lib/libQt6Test.so.6.9.1)
==26739==    by 0x502A0B5: QTest::qExec(QObject*, int, char**) (in /usr/lib/libQt6Test.so.6.9.1)
==26739==    by 0x4007636: main (testresultstree.cpp:37)
==26739==  Uninitialised value was created by a heap allocation
==26739==    at 0x4861F93: operator new(unsigned long) (vg_replace_malloc.c:487)
==26739==    by 0x400A9F8: QMap<QString, QVariant>::detach() (qmap.h:279)
==26739==    by 0x4009DDF: QMap<QString, QVariant>::operator[](QString const&) (qmap.h:379)
==26739==    by 0x400730C: TestResultsTree::test1() const (testresultstree.cpp:27)
==26739==    by 0x40046FF: TestResultsTree::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_testresultstree.cpp:72)
==26739==    by 0x5B2E19A: QMetaMethodInvoker::invokeImpl(QMetaMethod, void*, Qt::ConnectionType, long long, void const* const*, char const* const*, QtPrivate::QMetaTypeInterface const* const*) (in /usr/lib/libQt6Core.so.6.9.1)
==26739==    by 0x5B2EA3E: QMetaMethod::invokeImpl(QMetaMethod, void*, Qt::ConnectionType, long long, void const* const*, char const* const*, QtPrivate::QMetaTypeInterface const* const*) (in /usr/lib/libQt6Core.so.6.9.1)
==26739==    by 0x50187AE: ??? (in /usr/lib/libQt6Test.so.6.9.1)
==26739==    by 0x501BA81: ??? (in /usr/lib/libQt6Test.so.6.9.1)
==26739==    by 0x502916F: QTest::qRun() (in /usr/lib/libQt6Test.so.6.9.1)
==26739==    by 0x502A0B5: QTest::qExec(QObject*, int, char**) (in /usr/lib/libQt6Test.so.6.9.1)
==26739==    by 0x4007636: main (testresultstree.cpp:37)

@firewave firewave changed the title fixed #13223 - dynamically allocate model in ResultsTree (fixes TestResultsTree::test1()) refs #13223 - dynamically allocate model in ResultsTree Sep 17, 2025
@firewave firewave marked this pull request as ready for review September 17, 2025 05:33
@sonarqubecloud
Copy link
Copy Markdown

@firewave
Copy link
Copy Markdown
Collaborator Author

firewave commented Sep 17, 2025

If you call setModel() you get the pointer of the previously model and are supposed to delete that. So dynamically allocate it to be in line with that. Unfortunately this does not fix anything and the minimal reproducer for the actual issue is in the related ticket.

@danmar
Copy link
Copy Markdown
Owner

danmar commented Sep 23, 2025

Unfortunately this does not fix anything and the minimal reproducer for the actual issue is in the related ticket.

Can you please clarify if this PR fix the issue and you want it merged?

@firewave
Copy link
Copy Markdown
Collaborator Author

Can you please clarify if this PR fix the issue and you want it merged?

It does not fix the issue (I removed the reference from the title) - and I want it merged as it correctly implements the usage of a model.

@firewave firewave changed the title refs #13223 - dynamically allocate model in ResultsTree dynamically allocate model in ResultsTree Sep 23, 2025
Copy link
Copy Markdown
Owner

@danmar danmar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it feels like somebody else will someday try to change this back to avoid that new is used..

@firewave firewave merged commit 5131a05 into danmar:main Oct 2, 2025
61 checks passed
@firewave firewave deleted the resultstree-crash branch October 2, 2025 10:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants