tl;dr - Replace QVariantMap/toMap() usage in ResultsTree/ResultsView classes with QVariantHash/toHash() for performance and segfault avoidance
I've experienced cppcheck-gui crashes inside the resultsTree::updateFromOldReport method when built using Qt 6 (No crashes with Qt 5). After much flailing, it appears that the crash is occurring in the dtor for the QVariantMap stored in the QStandardItem using the setData() method, specifically when the initial QVariantMap is being replaced with an update. As far as I can tell, there's nothing being done in the cppcheck code that's causing the segfault. I suspect the problem is either with the underlying Qt libs or an ABI mismatch in the pre-built Qt libs I'm using between the build machine and my machine. Running/building on RHEL8
I also discovered that simply changing the QVariantMap to a QVariantHash fixes the problem (updates required in ResultsView and ResultsTree classes. Normally I wouldn't recommend changes because of a bug in an underlying library, but in this case, I can't see any reason a QMap was used instead of a QHash. QMap enforces sorting of the keys, which doesn't seem to be used/required, so the use of the QVariantMap is actually introducing some unnecessary overhead that transitioning to a QVariantHash would eliminate. Plus, it would also fix the crash bug that I (and I suspect some others) are encountering.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed that cppcheck-gui crashes as soon as in resultstree.cpp the rows are deleted by this:
void ResultsTree::clear()
{
mModel.removeRows(0, mModel.rowCount());
}
If mModel.rowCount() is 0, then all is fine. But as soon as mModel.rowCount() is >0 it crashes.
Maybe someone is able to code a minimum example and report this as Qt bug? I am sadly not skilled enough to write a small minimum example of this bug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can still reproduce it always. So it is not a random crash and also restart doesn't help. It is easy to reproduce the crash. I also updated the the latest Qt 6 version and also to the current Qt preview. But cppcheck always crashes as soon as I scan my test file a second time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe this is a side effect of https://trac.cppcheck.net/ticket/12316. The effects appears to be different. On one system it just causes an error printed to the terminal and on another it crashes with SIGFPE on start-up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
tl;dr - Replace QVariantMap/toMap() usage in ResultsTree/ResultsView classes with QVariantHash/toHash() for performance and segfault avoidance
I've experienced cppcheck-gui crashes inside the resultsTree::updateFromOldReport method when built using Qt 6 (No crashes with Qt 5). After much flailing, it appears that the crash is occurring in the dtor for the QVariantMap stored in the QStandardItem using the setData() method, specifically when the initial QVariantMap is being replaced with an update. As far as I can tell, there's nothing being done in the cppcheck code that's causing the segfault. I suspect the problem is either with the underlying Qt libs or an ABI mismatch in the pre-built Qt libs I'm using between the build machine and my machine. Running/building on RHEL8
I also discovered that simply changing the QVariantMap to a QVariantHash fixes the problem (updates required in ResultsView and ResultsTree classes. Normally I wouldn't recommend changes because of a bug in an underlying library, but in this case, I can't see any reason a QMap was used instead of a QHash. QMap enforces sorting of the keys, which doesn't seem to be used/required, so the use of the QVariantMap is actually introducing some unnecessary overhead that transitioning to a QVariantHash would eliminate. Plus, it would also fix the crash bug that I (and I suspect some others) are encountering.
I noticed that cppcheck-gui crashes as soon as in resultstree.cpp the rows are deleted by this:
void ResultsTree::clear()
{
mModel.removeRows(0, mModel.rowCount());
}
If mModel.rowCount() is 0, then all is fine. But as soon as mModel.rowCount() is >0 it crashes.
Maybe someone is able to code a minimum example and report this as Qt bug? I am sadly not skilled enough to write a small minimum example of this bug.
This looks similar to an issue I was having: https://trac.cppcheck.net/ticket/12229.
For some reason this just disappeared. I assume it some temporary issue caused by packages being updated and requiring a restart.
I can still reproduce it always. So it is not a random crash and also restart doesn't help. It is easy to reproduce the crash. I also updated the the latest Qt 6 version and also to the current Qt preview. But cppcheck always crashes as soon as I scan my test file a second time.
Maybe this is a side effect of https://trac.cppcheck.net/ticket/12316. The effects appears to be different. On one system it just causes an error printed to the terminal and on another it crashes with SIGFPE on start-up.
I just tried the new cppcheck 2.14.0 with Qt 6.6.2. It still crashes :-(
FFS.
Which compiler are you using?
How do you install the Qt libraries?
Which architecture are you using?
Can you reproduce the crash with this test?
https://github.com/danmar/cppcheck/pull/6571
To compile and run that you can for instance run these commands: