cgilles

How to reproduce : 1/ Checkout whole digiKam code from the git repository : git clone https://invent.kde.org/graphics/digikam.git ./ DIGIKAM 2/ Checkout cppcheck code from github repository, configure and install in /opt : git clone https://github.com/danmar/cppcheck.git ./CPPCHECK cp ./DIGIKAM/project/scripts/bootstrap-cppcheck.sh ./CPPCHECK cd ./CPPCHECK && ./bootstrap-cppcheck.sh && cd build && make sudo make install/fast 3/ Edit the cppcheck configuration in ./DIGIKAM/.cppcheck to drop the line...

Hi, I can confirm the bug with the cppcheck thread crashed in core/libs/dimg/filters/greycstoration/greycstorationfilter.cpp. I disable the cppcheck scan in this directory, and the scan now take 10 mn only. The crash is not relevant of large threads created while scanning under linux but a crash due to huge implementation from this directory. It contains a copy of the CImg C+++ header (an image processing lib implemented in of header only): https://invent.kde.org/graphics/digikam/-/tree/master/core/libs/dimg/filters/greycstoration/cimg?ref_type=heads...

I can confirm a bug here. Running cppcheck in gdb from my script. Pressing CTRL+C while the stage 2/. Continue in debugger quit the cppcheck instance properly. The script continue and generate the html export, which is "DIFFERENT" than one generated if not running in GDB after few hours to process the stage 2/ What i means by "DIFFERENT": instead to have 200 reports with the long analysis, i obtain over 3900 reports which are right and suitable. So i can conclude that something lock the stage 2/...

It always break at line 325 of processexecutor.cpp: 2056/2065 files checked 99% done 2057/2065 files checked 99% done 2058/2065 files checked 99% done 2059/2065 files checked 99% done 2060/2065 files checked 99% done 2061/2065 files checked 99% done 2062/2065 files checked 99% done 2063/2065 files checked 99% done 2064/2065 files checked 99% done ^C Program received signal SIGINT, Interrupt. 0x00007ffff7926c3e in __GI___select (nfds=18, readfds=0x7fffffff34a0, writefds=0x0, exceptfds=0x0, timeout=0x7fffffff33d0)...

In GDB, this is where the code run when cache is cleaned and analysis works for a while: _GPHOTO2=1;HAVE_PANORAMA=1;HAVE_X11=1;HAVE_X265=1;HAVE_DBUS=1;HAVE_LENSFUN=1;HAVE_HEIF=1;HAVE_JXL=1;HAVE_EIGEN3=1;HAVE_JASPER=1;HAVE_IMAGE_MAGICK=1;_XMP_SUPPORT_=1... 2039/2065 files checked 97% done Checking ../../core/utilities/setup/metadata/setupmetadata_rotation.cpp: Q_OS_LINUX=1;Q_OS_UNIX=1;Q_PROCESSOR_X86_64=1;HAVE_GEOLOCATION=1;HAVE_MEDIA_PLAYER=1;HAVE_QWEBENGINE=1;HAVE_QTMULTIMEDIA=1;HAVE_OPENGL=1;HAVE_MYSQLSUPPORT=1;HAVE_INTERNALMYSQL=1;HAVE_GPHOTO2=1;HAVE_PANORAMA=1;HAVE_X11=1;HAVE_X265=1;HAVE_DBUS=1;HAVE_LENSFUN=1;HAVE_HEIF=1;HAVE_JXL=1;HAVE_EIGEN3=1;HAVE_JASPER=1;HAVE_IMAGE_MAGICK=1;_XMP_SUPPORT_=1......

Hi, First test with the cache dir enabled, the analysis take 10 seconds only. It's very impressive. Best Gilles Caulier

So all source files have already been processed when stage 2 begins, correct? I supose, as no more message appears on the console. In fact the console trace is like below: ... 2037/2065 files checked 97% done 2038/2065 files checked 97% done Checking ../../core/utilities/setup/metadata/setupmetadata_p.cpp: Q_OS_LINUX=1;Q_OS_UNIX=1;Q_PROCESSOR_X86_64=1;HAVE_GEOLOCATION=1;HAVE_MEDIA_PLAYER=1;HAVE_QWEBENGINE=1;HAVE_QTMULTIMEDIA=1;HAVE_OPENGL=1;HAVE_MYSQLSUPPORT=1;HAVE_INTERNALMYSQL=1;HAVE_GPHOTO2=1;HAVE_PANORAMA=1;HAVE_X11=1;HAVE_X265=1;HAVE_DBUS=1;HAVE_LENSFUN=1;HAVE_HEIF=1;HAVE_JXL=1;HAVE_EIGEN3=1;HAVE_JASPER=1;HAVE_IMAGE_MAGICK=1;XMP_SUPPORT=1......

Hum the --inconclusive and the cache dir enabled do not change anything. Only one cppcheck process run at analysis time at 3% of CPU. Anyway the cache mechanism gain will be only visible at the next analysis as it's the first time that i turn on this option. Nota: the file parsing stage at stage 1/ is paralelized and 31 cppcheck instance run at the same time while this process. At stage 2/, only one cppcheck still in memory and run alone. Best Gilles Caulier