> #5  0x00007f81bb18e2d4 in  () at /usr/lib/qt/plugins/kdevplatform/36/kdevcmakemanager.so
Could you please build KDevelop with debug symbols to generate a more useful backtrace? Or try to download the debug symbols via https://wiki.archlinux.org/title/Debugging/Getting_traces#Debuginfod.

(In reply to Igor Kushnir from comment #1)
> > #5  0x00007f81bb18e2d4 in  () at /usr/lib/qt/plugins/kdevplatform/36/kdevcmakemanager.so
> Could you please build KDevelop with debug symbols to generate a more useful
> backtrace? Or try to download the debug symbols via
> https://wiki.archlinux.org/title/Debugging/Getting_traces#Debuginfod.

Yes, will try to do provide debug info.

.. after downloading debuginfo, repeating the crash procedure, and using gdb,(konqi seems to disable/or not read .gdb.ini file, will sort out that later),,
here seems to be the intersting spots:

#7  0x00007fc16bf7faad in CMakeManager::projectClosing (this=0x5646c97164f0, p=<optimized out>) at /usr/src/debug/kdevelop-22.04.2/plugins/cmake/cmakemanager.cpp:660
660             cleanupTestSuites(it->testSuites, it->testSuiteJobs);
(gdb) l
655
656     void CMakeManager::projectClosing(IProject* p)
657     {
658         auto it = m_projects.find(p);
659         if (it != m_projects.end()) {
660             cleanupTestSuites(it->testSuites, it->testSuiteJobs);
661             m_projects.erase(it);
662         }
663     }
664
(gdb) down
#6  0x00007fc16bf912d4 in cleanupTestSuites(QVector<CTestSuite*> const&, QVector<CTestFindJob*> const&) [clone .isra.0] (testSuites=..., testSuiteJobs=...)
    at /usr/src/debug/kdevelop-22.04.2/plugins/cmake/cmakemanager.cpp:440
440             delete testSuite;
(gdb) list
435         for (auto* testSuiteJob : testSuiteJobs) {
436             testSuiteJob->kill(KJob::Quietly);
437         }
438         for (auto* testSuite : testSuites) {
439             ICore::self()->testController()->removeTestSuite(testSuite);
440             delete testSuite;
441         }
442     }
443
444     void CMakeManager::integrateData(const CMakeProjectData &data, KDevelop::IProject* project, const QSharedPointer<CMakeServer>& server)
(gdb) down
#5  0x0000000000000031 in ?? ()

(In reply to Sigbjorn from comment #3)
> .. after downloading debuginfo, repeating the crash procedure, and using
> gdb,(konqi seems to disable/or not read .gdb.ini file, will sort out that
> later),,
> here seems to be the intersting spots:
> 
> #7  0x00007fc16bf7faad in CMakeManager::projectClosing (this=0x5646c97164f0,
> p=<optimized out>) at
> /usr/src/debug/kdevelop-22.04.2/plugins/cmake/cmakemanager.cpp:660
> 660             cleanupTestSuites(it->testSuites, it->testSuiteJobs);
> (gdb) l
> 655
> 656     void CMakeManager::projectClosing(IProject* p)
> 657     {
> 658         auto it = m_projects.find(p);
> 659         if (it != m_projects.end()) {
> 660             cleanupTestSuites(it->testSuites, it->testSuiteJobs);
> 661             m_projects.erase(it);
> 662         }
> 663     }
> 664
> (gdb) down
> #6  0x00007fc16bf912d4 in cleanupTestSuites(QVector<CTestSuite*> const&,
> QVector<CTestFindJob*> const&) [clone .isra.0] (testSuites=...,
> testSuiteJobs=...)
>     at /usr/src/debug/kdevelop-22.04.2/plugins/cmake/cmakemanager.cpp:440
> 440             delete testSuite;
> (gdb) list
> 435         for (auto* testSuiteJob : testSuiteJobs) {
> 436             testSuiteJob->kill(KJob::Quietly);
> 437         }
> 438         for (auto* testSuite : testSuites) {
> 439             ICore::self()->testController()->removeTestSuite(testSuite);
> 440             delete testSuite;
> 441         }
> 442     }
> 443
> 444     void CMakeManager::integrateData(const CMakeProjectData &data,
> KDevelop::IProject* project, const QSharedPointer<CMakeServer>& server)
> (gdb) down
> #5  0x0000000000000031 in ?? ()

-------------------
bt 15 looks like:
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=11, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007fc1aea8e3d3 in __pthread_kill_internal (signo=11, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007fc1aea3e838 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
#3  0x00007fc1b0e17840 in KCrash::defaultCrashHandler(int) (sig=11) at /usr/src/debug/kcrash-5.95.0/src/kcrash.cpp:633
#4  0x00007fc1aea3e8e0 in <signal handler called> () at /usr/lib/libc.so.6
#5  0x0000000000000031 in  ()
#6  0x00007fc16bf912d4 in cleanupTestSuites(QVector<CTestSuite*> const&, QVector<CTestFindJob*> const&) [clone .isra.0] (testSuites=..., testSuiteJobs=<optimized out>)
    at /usr/src/debug/kdevelop-22.04.2/plugins/cmake/cmakemanager.cpp:440
#7  0x00007fc16bf7faad in CMakeManager::projectClosing(KDevelop::IProject*) (this=0x5646c97164f0, p=<optimized out>)
    at /usr/src/debug/kdevelop-22.04.2/plugins/cmake/cmakemanager.cpp:660
#8  0x00007fc1af4bd621 in QtPrivate::QSlotObjectBase::call(QObject*, void**)
    (a=0x7fff67a1f820, r=<optimized out>, this=0x5646c9719b60, this=<optimized out>, r=<optimized out>, a=<optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#9  doActivate<false>(QObject*, int, void**) (sender=0x5646c6b55210, signal_index=5, argv=0x7fff67a1f820) at kernel/qobject.cpp:3886
#10 0x00007fc1b0e37867 in KDevelop::IProjectController::projectClosing(KDevelop::IProject*) (this=this@entry=0x5646c6b55210, _t1=<optimized out>, 
    _t1@entry=0x5646c9a60b30) at /usr/src/debug/build/kdevplatform/interfaces/KDevPlatformInterfaces_autogen/EWIEGA46WW/moc_iprojectcontroller.cpp:273
#11 0x00007fc1b0f45ada in KDevelop::ProjectController::takeProject(KDevelop::IProject*) (this=0x5646c6b55210, proj=<optimized out>)
    at /usr/src/debug/kdevelop-22.04.2/kdevplatform/shell/projectcontroller.cpp:1059
#12 0x00007fc1b0f47686 in KDevelop::ProjectController::closeProject(KDevelop::IProject*) (proj=0x5646c9a60b30, this=0x5646c6b55210)
    at /usr/src/debug/kdevelop-22.04.2/kdevplatform/shell/projectcontroller.cpp:1077
#13 KDevelop::ProjectController::closeAllProjects() (this=0x5646c6b55210) at /usr/src/debug/kdevelop-22.04.2/kdevplatform/shell/projectcontroller.cpp:1089
#14 0x00007fc1b0f37c18 in KDevelop::Core::cleanup() (this=0x5646c67c9760) at /usr/src/debug/kdevelop-22.04.2/kdevplatform/shell/core.cpp:374

(In reply to Sigbjorn from comment #4)
> (In reply to Sigbjorn from comment #3)
> > .. after downloading debuginfo, repeating the crash procedure, and using
> > gdb,(konqi seems to disable/or not read .gdb.ini file, will sort out that
> > later),,
> > here seems to be the intersting spots:
> > 
> > #7  0x00007fc16bf7faad in CMakeManager::projectClosing (this=0x5646c97164f0,
> > p=<optimized out>) at
> > /usr/src/debug/kdevelop-22.04.2/plugins/cmake/cmakemanager.cpp:660
> > 660             cleanupTestSuites(it->testSuites, it->testSuiteJobs);
> > (gdb) l
> > 655
> > 656     void CMakeManager::projectClosing(IProject* p)
> > 657     {
> > 658         auto it = m_projects.find(p);
> > 659         if (it != m_projects.end()) {
> > 660             cleanupTestSuites(it->testSuites, it->testSuiteJobs);
> > 661             m_projects.erase(it);
> > 662         }
> > 663     }
> > 664
> > (gdb) down
> > #6  0x00007fc16bf912d4 in cleanupTestSuites(QVector<CTestSuite*> const&,
> > QVector<CTestFindJob*> const&) [clone .isra.0] (testSuites=...,
> > testSuiteJobs=...)
> >     at /usr/src/debug/kdevelop-22.04.2/plugins/cmake/cmakemanager.cpp:440
> > 440             delete testSuite;
> > (gdb) list
> > 435         for (auto* testSuiteJob : testSuiteJobs) {
> > 436             testSuiteJob->kill(KJob::Quietly);
> > 437         }
> > 438         for (auto* testSuite : testSuites) {
> > 439             ICore::self()->testController()->removeTestSuite(testSuite);
> > 440             delete testSuite;
> > 441         }
> > 442     }
> > 443
> > 444     void CMakeManager::integrateData(const CMakeProjectData &data,
> > KDevelop::IProject* project, const QSharedPointer<CMakeServer>& server)
> > (gdb) down
> > #5  0x0000000000000031 in ?? ()
> 
> -------------------
> bt 15 looks like:
> #0  __pthread_kill_implementation (threadid=<optimized out>,
> signo=signo@entry=11, no_tid=no_tid@entry=0) at pthread_kill.c:44
> #1  0x00007fc1aea8e3d3 in __pthread_kill_internal (signo=11,
> threadid=<optimized out>) at pthread_kill.c:78
> #2  0x00007fc1aea3e838 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
> #3  0x00007fc1b0e17840 in KCrash::defaultCrashHandler(int) (sig=11) at
> /usr/src/debug/kcrash-5.95.0/src/kcrash.cpp:633
> #4  0x00007fc1aea3e8e0 in <signal handler called> () at /usr/lib/libc.so.6
> #5  0x0000000000000031 in  ()
> #6  0x00007fc16bf912d4 in cleanupTestSuites(QVector<CTestSuite*> const&,
> QVector<CTestFindJob*> const&) [clone .isra.0] (testSuites=...,
> testSuiteJobs=<optimized out>)
>     at /usr/src/debug/kdevelop-22.04.2/plugins/cmake/cmakemanager.cpp:440
> #7  0x00007fc16bf7faad in CMakeManager::projectClosing(KDevelop::IProject*)
> (this=0x5646c97164f0, p=<optimized out>)
>     at /usr/src/debug/kdevelop-22.04.2/plugins/cmake/cmakemanager.cpp:660
> #8  0x00007fc1af4bd621 in QtPrivate::QSlotObjectBase::call(QObject*, void**)
>     (a=0x7fff67a1f820, r=<optimized out>, this=0x5646c9719b60,
> this=<optimized out>, r=<optimized out>, a=<optimized out>)
>     at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
> #9  doActivate<false>(QObject*, int, void**) (sender=0x5646c6b55210,
> signal_index=5, argv=0x7fff67a1f820) at kernel/qobject.cpp:3886
> #10 0x00007fc1b0e37867 in
> KDevelop::IProjectController::projectClosing(KDevelop::IProject*)
> (this=this@entry=0x5646c6b55210, _t1=<optimized out>, 
>     _t1@entry=0x5646c9a60b30) at
> /usr/src/debug/build/kdevplatform/interfaces/KDevPlatformInterfaces_autogen/
> EWIEGA46WW/moc_iprojectcontroller.cpp:273
> #11 0x00007fc1b0f45ada in
> KDevelop::ProjectController::takeProject(KDevelop::IProject*)
> (this=0x5646c6b55210, proj=<optimized out>)
>     at
> /usr/src/debug/kdevelop-22.04.2/kdevplatform/shell/projectcontroller.cpp:1059
> #12 0x00007fc1b0f47686 in
> KDevelop::ProjectController::closeProject(KDevelop::IProject*)
> (proj=0x5646c9a60b30, this=0x5646c6b55210)
>     at
> /usr/src/debug/kdevelop-22.04.2/kdevplatform/shell/projectcontroller.cpp:1077
> #13 KDevelop::ProjectController::closeAllProjects() (this=0x5646c6b55210) at
> /usr/src/debug/kdevelop-22.04.2/kdevplatform/shell/projectcontroller.cpp:1089
> #14 0x00007fc1b0f37c18 in KDevelop::Core::cleanup() (this=0x5646c67c9760) at
> /usr/src/debug/kdevelop-22.04.2/kdevplatform/shell/core.cpp:374

...........
running gdb kdevelop, catching the error, and printing the testSuite it tries to delete :
(gdb) p *testSuite
$3 = {<KDevelop::ITestSuite> = {_vptr.ITestSuite = 0x398}, m_executable = {m_data = {d = 0x0}}, 
  m_name = {d = 0x0}, 
  m_cases = {<QList<QString>> = {<QListSpecialMethods<QString>> = {<No data fields>}, {p = {
          static shared_null = {ref = {atomic = {_q_value = std::atomic<int> = { -1 }}}, alloc = 0, 
            begin = 0, end = 0, array = {0x0}}, d = 0x400000004000}, 
        d = 0x400000004000}}, <No data fields>}, 
  m_args = {<QList<QString>> = {<QListSpecialMethods<QString>> = {<No data fields>}, {p = {
          static shared_null = {ref = {atomic = {_q_value = std::atomic<int> = { -1 }}}, alloc = 0, 
            begin = 0, end = 0, array = {0x0}}, d = 0x0}, d = 0x0}}, <No data fields>}, 
  m_files = {<QListSpecialMethods<KDevelop::Path>> = {<No data fields>}, {p = {static shared_null = {
          ref = {atomic = {_q_value = std::atomic<int> = { -1 }}}, alloc = 0, begin = 0, end = 0, 
          array = {0x0}}, d = 0x200000000}, d = 0x200000000}}, m_project = {wp = {d = 0x555557a125b0, 
      value = 0x0}}, m_declarations = {{d = 0x0, e = 0x0}}, m_properties = {{d = 0x80000000, 
      e = 0x80000000}}, m_suiteDeclaration = {m_topContext = 1502338080, m_declarationIndex = 21845}}
....

Based on the stack/listing etc. it seems to be related to the cmake-manager test suite handling.

Other observations of interest:

(0) Re-generating cmake after cmake-file changes, also crashes  the kdevelop (will check on the exact location later, .. is it the same?)
(1) If I disable test (cmake will not generate  ctest suite cmds etc.), there is  no crash

..................
Based on the above my guess is that it might be the cmake manager handling of test-suites info as generated by the cmake command.
In my case, gitlab.com/shyft-os/shyft, using doctest c++ suite,  there will be test-cases with labels, strings, descriptions of any size, so maybe there is something in that area that causes the problems.

there that causes

The test suite code is somewhat messy and buggy. I have started fixing it more than a year ago, but sadly postponed that work in favor of other fixes/improvements. If you want to try and fix this issue, I could share my WIP changes. If not, try disabling KDevelop's Unit Test View plugin as a workaround.

Investigations:

Using the doctest (gitlab.com/doctest), generates test-cases, that are picked up and enlisted by the test executable it self.
In doctest, there test might be grouped into test-suites, and test-cases are 'scoped' to test-suites, so there are no conflicts,  - in doctest.

However, the cmake/integration exports the test-case names, that might be duplicates.

Creating a minimal  cmake  doctest example, with two test-suites, and within each of them, repeats the crash, at the same spot.

A simple workaround to avoid crash during exit, or regeneration of  cmake-files, is just to ensure all test-cases are unique.

Further investigation & resolution could pinpoint the exact cause, and strengthen the cmake/ctest manager so that it handles duplicate test-cases, one way or another (not crashing :-)).

(In reply to Igor Kushnir from comment #7)
> The test suite code is somewhat messy and buggy. I have started fixing it
> more than a year ago, but sadly postponed that work in favor of other
> fixes/improvements. If you want to try and fix this issue, I could share my
> WIP changes. If not, try disabling KDevelop's Unit Test View plugin as a
> workaround.

Hi, thanks for responding.
As pr my latest investigation, it seems that if there is a duplicate test-case within the suite, that triggers the error.
I guess there is an assumption somewhere that they are unique, but not enforced/handled, so it surfaces as a crash during
destruction of the test-suite structures.

For this there is a workaround, that is, ensure there is no duplicate test-cases enlisted in tests.

(In reply to Sigbjorn from comment #9)
> (In reply to Igor Kushnir from comment #7)
> > The test suite code is somewhat messy and buggy. I have started fixing it
> > more than a year ago, but sadly postponed that work in favor of other
> > fixes/improvements. If you want to try and fix this issue, I could share my
> > WIP changes. If not, try disabling KDevelop's Unit Test View plugin as a
> > workaround.
> 
> Hi, thanks for responding.
> As pr my latest investigation, it seems that if there is a duplicate
> test-case within the suite, that triggers the error.
> I guess there is an assumption somewhere that they are unique, but not
> enforced/handled, so it surfaces as a crash during
> destruction of the test-suite structures.
> 
> For this there is a workaround, that is, ensure there is no duplicate
> test-cases enlisted in tests.
Thanks for the investigation. I'll take a look at this duplicate issue when I resume work on test suite fixing.

> However, the cmake/integration exports the test-case names, that might be duplicates.
> Creating a minimal  cmake  doctest example, with two test-suites, and within each of them, repeats the crash, at the same spot.
Could you attach a sample project that triggers the crash?

(In reply to Igor Kushnir from comment #10)
> (In reply to Sigbjorn from comment #9)
> > (In reply to Igor Kushnir from comment #7)
> > > The test suite code is somewhat messy and buggy. I have started fixing it
> > > more than a year ago, but sadly postponed that work in favor of other
> > > fixes/improvements. If you want to try and fix this issue, I could share my
> > > WIP changes. If not, try disabling KDevelop's Unit Test View plugin as a
> > > workaround.
> > 
> > Hi, thanks for responding.
> > As pr my latest investigation, it seems that if there is a duplicate
> > test-case within the suite, that triggers the error.
> > I guess there is an assumption somewhere that they are unique, but not
> > enforced/handled, so it surfaces as a crash during
> > destruction of the test-suite structures.
> > 
> > For this there is a workaround, that is, ensure there is no duplicate
> > test-cases enlisted in tests.
> Thanks for the investigation. I'll take a look at this duplicate issue when
> I resume work on test suite fixing.
> 
> > However, the cmake/integration exports the test-case names, that might be duplicates.
> > Creating a minimal  cmake  doctest example, with two test-suites, and within each of them, repeats the crash, at the same spot.
> Could you attach a sample project that triggers the crash?

Yes, will do so, might take some hours, to minimise deps to just cmake/ctest.

Created attachment 149999 [details]
minimal example that illustrates the crash

also available here https://gitlab.com/sigbjorn.helset/kdev-issue-support.git

The provided example is minimal, and emulates the effects when using multiple test binaries, or delayed test-generation that gives similar effects for even a single binary test project.

Thanks for the great sample project. Just reproduced the crash on KDevelop exit at the first try.

*** Bug 448410 has been marked as a duplicate of this bug. ***

just wanted to add that i experience this too:
dist: openSUSE LEAP 15.4
kdevelop Version 5.7.211203 (21.12.3)
KDE Plasma: 5.24.4
kernel: Linux unknown309c23cd67ab 5.14.21-150400.22-default #1 SMP PREEMPT_DYNAMIC Wed May 11 06:57:18 UTC 2022 (49db222) x86_64 x86_64 x86_64 GNU/Linux

after exiting kdevelop: the CPU-load of kdevelop is maxed out and it has a bash child process
KILL (kill -9) is necessary (TERM (kill -15) has no effect)

(In reply to zb4ng from comment #16)
> after exiting kdevelop: the CPU-load of kdevelop is maxed out and it has a
> bash child process
> KILL (kill -9) is necessary (TERM (kill -15) has no effect)
This bug report is about a crash on exit, not freeze. Could you be experiencing Bug 379669?

(In reply to Igor Kushnir from comment #17)
> This bug report is about a crash on exit, not freeze. Could you be
> experiencing Bug 379669?

You are right. I am sorry, I have missed this while reading...

In my setup, this bug was caused by duplicated add_test statements.

(In reply to Gabriele Menna from comment #19)
> In my setup, this bug was caused by duplicated add_test statements.

Yes, this is according to the  minimal example provided, that triggers the errors. Two test-suites(as executable files), where there is a name-clash.