[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #51 from RJVB  ---
I too only seem to be getting this crash only sporadically nowadays, and AFAICT
there's (almost) always a prematurely unloaded language plugin involved. But
I'm pretty certain it does not only occur after working with a duchain (or
whatever) cache left corrupted by a crash. In fact, the last case I had was
after that entire cache had been discarded because created by a previous
KDevelop version.

Then again, I still use my own patch that removes the most obvious assumptions
that can lead to nullptr dereference or dead loops as above, AND I install a
timer that raises (IIRC) a SIGHUP after it expires (60s).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Igor Kushnir]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #50 from Igor Kushnir  ---
I rarely experience freeze on exit and even more rarely this particular freeze
(lately, once a year perhaps despite heavy KDevelop use). Yesterday I got the
currentIndex=0 freeze. Note the `followerIndex (index=0,` part in the following
call stack extract:

0x7fbfc51630dd in KDevelop::Bucket::followerIndex (index=0,
this=) at
/path/to/kdevelop/kdevplatform/serialization/itemrepository.h:1070
1070return *reinterpret_cast(m_data + (index -
2));
#0  0x7fbfc51630dd in KDevelop::Bucket::followerIndex (index=0,
this=) at
/path/to/kdevelop/kdevplatform/serialization/itemrepository.h:1070
#1  KDevelop::Bucket::deleteItem >
(repository=, hash=, index=44482,
this=0x7fbf0cbc5ad0) at
/path/to/kdevelop/kdevplatform/serialization/itemrepository.h:628
#2  KDevelop::Bucket::finalCleanup >
(repository=, this=) at
/path/to/kdevelop/kdevplatform/serialization/itemrepository.h:791

KDevelop occupied a CPU core by the infinite loop `while (currentIndex !=
index)` for half an hour, until I terminated the KDevelop process. I verified
this by comparing GDB call stacks generated with the half-hour interval: all
addresses and arguments are exactly the same, until the line
itemrepository.h:626 in one and itemrepository.h:628 in another call stack.
These two line numbers correspond to the source code lines `while (currentIndex
!= index) {` and `currentIndex = followerIndex(currentIndex);` (inside the
loop) respectively.

1.5 years ago I got this same freeze after a blackout and consequently a sudden
system shutdown in KDevelop::Bucket, that is, probably because of cache
corruption.

Yesterday I repeatedly removed and installed kdev-python, KDevelop parsing of a
.py file hanged and I was forced to restart KDevelop. The freeze in
KDevelop::Bucket occurred during the next exit of the same KDevelop session. So again
it is a consequence of either missing language plugin or a related cache
corruption.

I think that due to performance considerations cache corruption inevitably
leads to undefined behavior. If the undefined behavior often manifests in the
same freeze, then we can try to work it around. An acceptable workaround should
be able to at least sometimes solve the problem automatically, possibly by
clearing the cache automatically or *insisting* that the user agrees to clear
the cache. Obviously no workaround can be 100% reliable in the face of
undefined behavior.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Igor Kushnir]

https://bugs.kde.org/show_bug.cgi?id=379669

Igor Kushnir  changed:

   What|Removed |Added

 CC||joerg.stre...@gmail.com

--- Comment #49 from Igor Kushnir  ---
*** Bug 472669 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Aaron Williams]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #48 from Aaron Williams  ---
I am still seeing this in the latest release.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #47 from RJVB  ---
> The problem is that currentIndex is 0 and it never bails out. This is with
> the very latest release.

IIRC this is one of the things my patch addresses.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Aaron Williams]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #46 from Aaron Williams  ---
I too am getting the hangs on exit. In the debugger I see it failing in
KDevelop::Bucket::deleteItem > (repository=...,
hash=, index=29676, this=0x55850f6084f0) at
/usr/src/debug/kdevelop5-22.04.1-lp153.19.1.x86_64/kdevplatform/serialization/itemrepository.h:525

The problem is that currentIndex is 0 and it never bails out. This is with the
very latest release.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Igor Kushnir]

https://bugs.kde.org/show_bug.cgi?id=379669

Igor Kushnir  changed:

   What|Removed |Added

 CC||aar...@doofus.org

--- Comment #45 from Igor Kushnir  ---
*** Bug 454309 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Lemuel Simon]

https://bugs.kde.org/show_bug.cgi?id=379669

Lemuel Simon  changed:

   What|Removed |Added

 CC||lemuelsimo...@protonmail.co
   ||m

--- Comment #44 from Lemuel Simon  ---
*** Bug 448684 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #43 from RJVB  ---
I also am continuing to get hangs on exit, but a while back I implemented a
failsafe, a simple timer that raises a SIGHUP if the application doesn't exit
normally within 1 minute after starting the final cleanup. Nowadays that is
safer than it ever was (with the rest of my patch), as far as I can tell the
application is really waiting to exit when the timer fires.

NB: not a Qt timer of course, those wouldn't work anymore.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Igor Kushnir]

https://bugs.kde.org/show_bug.cgi?id=379669

Igor Kushnir  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=448166

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Raúl]

https://bugs.kde.org/show_bug.cgi?id=379669

Raúl  changed:

   What|Removed |Added

Version|5.6.1   |5.6.2

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Raúl]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #42 from Raúl  ---
  Hello:

  Still happening on 5.6.2. Debian testing, KDE Frameworks 5.78.0, Qt 5.15.2

Thread 23 (Thread 0x7f8b60f90700 (LWP 3684) "KDevelop::Compl"):
#0  0x7f8bf8da73ff in __GI___poll (fds=0x7f8b3809e7a0, nfds=1, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f8bf5aa50ae in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f8bf5aa51cf in g_main_context_iteration () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f8bf934d4bf in
QEventDispatcherGlib::processEvents(QFlags)
(this=0x7f8b384bbe70, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#4  0x7f8bf92f492b in
QEventLoop::exec(QFlags)
(this=this@entry=0x7f8b60f8fbe0, flags=..., flags@entry=...) at
../../include/QtCore/../../src/corelib/global/qflags.h:69
#5  0x7f8bf9113a3e in QThread::exec() (this=) at
../../include/QtCore/../../src/corelib/global/qflags.h:121
#6  0x7f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x55d9c4a66c20) at
thread/qthread_unix.cpp:329
#7  0x7f8bf6439ea7 in start_thread (arg=) at
pthread_create.c:477
#8  0x7f8bf8db1def in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 22 (Thread 0x7f8b63fff700 (LWP 3638) "Queue(0x55d9c2c"):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x55d9c2f81374) at
../sysdeps/nptl/futex-internal.h:186
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55d9c2f81320,
cond=0x55d9c2f81348) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x55d9c2f81348, mutex=0x55d9c2f81320) at
pthread_cond_wait.c:638
#3  0x7f8bf911aafb in QWaitConditionPrivate::wait(QDeadlineTimer)
(deadline=..., deadline=..., this=0x55d9c2f81320) at
thread/qwaitcondition_unix.cpp:146
#4  QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=,
mutex=0x55d9c30018c0, deadline=...) at thread/qwaitcondition_unix.cpp:225
#5  0x7f8bf5a3d214 in
ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned(ThreadWeaver::Thread*)
() at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x7f8bf5a41d8e in  () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x7f8bf5a3d0f2 in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at
/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x7f8bf5a3f670 in ThreadWeaver::Thread::run() () at
/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#9  0x7f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x7f8b5c004e10) at
thread/qthread_unix.cpp:329
#10 0x7f8bf6439ea7 in start_thread (arg=) at
pthread_create.c:477
#11 0x7f8bf8db1def in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 21 (Thread 0x7f8b7d7fa700 (LWP 3636) "Queue(0x55d9c2c"):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x55d9c2f81374) at
../sysdeps/nptl/futex-internal.h:186
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55d9c2f81320,
cond=0x55d9c2f81348) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x55d9c2f81348, mutex=0x55d9c2f81320) at
pthread_cond_wait.c:638
#3  0x7f8bf911aafb in QWaitConditionPrivate::wait(QDeadlineTimer)
(deadline=..., deadline=..., this=0x55d9c2f81320) at
thread/qwaitcondition_unix.cpp:146
#4  QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=,
mutex=0x55d9c30018c0, deadline=...) at thread/qwaitcondition_unix.cpp:225
--Type  for more, q to quit, c to continue without paging--c
#5  0x7f8bf5a3d214 in
ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned(ThreadWeaver::Thread*)
() at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x7f8bf5a41d8e in  () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x7f8bf5a3d0f2 in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at
/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x7f8bf5a3f670 in ThreadWeaver::Thread::run() () at
/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#9  0x7f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x7f8b680051f0) at
thread/qthread_unix.cpp:329
#10 0x7f8bf6439ea7 in start_thread (arg=) at
pthread_create.c:477
#11 0x7f8bf8db1def in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 20 (Thread 0x7f8b7dffb700 (LWP 3635) "Queue(0x55d9c2c"):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x55d9c2f81374) at
../sysdeps/nptl/futex-internal.h:186
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55d9c2f81320,
cond=0x55d9c2f81348) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x55d9c2f81348, mutex=0x55d9c2f81320) at
pthread_cond_wait.c:638
#3  0x7f8bf911aafb in QWaitConditionPrivate::wait(QDeadlineTimer)
(deadline=..., deadline=..., this=0x55d9c2f81320) at
thread/qwaitcondition_unix.cpp:146
#4  QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=,
mutex=0x55d9c30018c0, deadline=...) at thread/qwaitcondition_unix.cpp:225
#5  0x7f8bf5a3d214 in
ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned(ThreadWeaver::Thread*)
() at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Igor Kushnir]

https://bugs.kde.org/show_bug.cgi?id=379669

Igor Kushnir  changed:

   What|Removed |Added

 CC||igor...@gmail.com
Version|5.5.0   |5.6.1

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Piotr Keplicz]

https://bugs.kde.org/show_bug.cgi?id=379669

Piotr Keplicz  changed:

   What|Removed |Added

Version|5.4.6   |5.5.0

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Piotr Keplicz]

https://bugs.kde.org/show_bug.cgi?id=379669

Piotr Keplicz  changed:

   What|Removed |Added

 CC||kepl...@cmc.pl

--- Comment #41 from Piotr Keplicz  ---
Created attachment 127166
  --> https://bugs.kde.org/attachment.cgi?id=127166=edit
perf report

Here goes perf output from a stuck-on-exit kdevelop. I don't whether it's
useful, it's from 5.5.0.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Raúl]

https://bugs.kde.org/show_bug.cgi?id=379669

Raúl  changed:

   What|Removed |Added

Version|unspecified |5.4.6

--- Comment #40 from Raúl  ---
Hi!

This is just to remark that the bug is still hapenning on 5.4.6. See backtrace
below, sorry for not providing a full one. When this happens kdevelop CPU usage
rises to 100% and I had to kill it. Below the backtrace you can find a console
output excerpt, in case it helps. 

#0  0x7f9d947a5f35 in KDevelop::Bucket::deleteItem >(unsigned short,
unsigned int, KDevelop::ItemRepository&)
(repository=..., hash=, index=62268, this=0x7f9d380051f0) at
./kdevplatform/serialization/itemrepository.h:972
#1  0x7f9d947a5f35 in KDevelop::Bucket::finalCleanup
>(KDevelop::ItemRepository&) (repository=...,
this=)
at ./kdevplatform/serialization/itemrepository.h:696
#2  0x7f9d947a5f35 in KDevelop::ItemRepository::finalCleanup()
(this=) at ./kdevplatform/serialization/itemrepository.h:2195
#3  0x7f9d942b6999 in KDevelop::ItemRepositoryRegistry::finalCleanup()
(this=)
at ./kdevplatform/serialization/itemrepositoryregistry.cpp:383
#4  0x7f9d946de41a in KDevelop::finalCleanup () at
./kdevplatform/language/duchain/duchain.cpp:1704
#5  0x7f9d946de41a in KDevelop::DUChain::shutdown() (this=)
at ./kdevplatform/language/duchain/duchain.cpp:1742
#6  0x7f9d972ae646 in KDevelop::Core::cleanup() (this=0x55df81dbc9c0) at
./kdevplatform/shell/core.cpp:431
#7  0x7f9d972ae8dc in KDevelop::Core::shutdown() (this=0x55df81dbc9c0) at
./kdevplatform/shell/core.cpp:386
#8  0x7f9d9728da5d in KDevelop::MainWindow::~MainWindow()
(this=this@entry=0x55df81eebbc0, __in_chrg=,
__vtt_parm=)
at ./kdevplatform/shell/mainwindow.cpp:150
#9  0x7f9d9728dab9 in KDevelop::MainWindow::~MainWindow()
(this=0x55df81eebbc0, __in_chrg=, __vtt_parm=)
at ./kdevplatform/shell/mainwindow.cpp:146
#10 0x7f9d95c9e100 in QObject::event(QEvent*) () at
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7f9d9681b96b in QWidget::event(QEvent*) () at
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
--Type  for more, q to quit, c to continue without paging--
#12 0x7f9d96921d64 in QMainWindow::event(QEvent*) () at
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#13 0x7f9d93da717b in KMainWindow::event(QEvent*) () at
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#14 0x7f9d93df1115 in KXmlGuiWindow::event(QEvent*) () at
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#15 0x7f9d967dd4c1 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x7f9d967e4970 in QApplication::notify(QObject*, QEvent*) () at
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x7f9d95c744f9 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x7f9d95c774db in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x7f9d95cc6173 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x7f9d9228ef2e in g_main_context_dispatch () at
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x7f9d9228f1c8 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x7f9d9228f25c in g_main_context_iteration () at
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x7f9d95cc5797 in
QEventDispatcherGlib::processEvents(QFlags) ()
at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x7f9d88398401 in  () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#25 0x7f9d95c731cb in
QEventLoop::exec(QFlags) () at
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#26 0x7f9d95c7b1a2 in QCoreApplication::exec() () at
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#27 0x55df81b253ac in main(int, char**) (argc=,
argv=) at ./app/main.cpp:852


UdevQt: unhandled device action "unbind"
UdevQt: unhandled device action "unbind"
UdevQt: unhandled device action "bind"
UdevQt: unhandled device action "bind"
kdevplatform.language: item index out of bounds: 36 count: 19
kdevplatform.language: item index out of bounds: 35 count: 19
kdevplatform.language: item index out of bounds: 33 count: 19
kdevplatform.language: item index out of bounds: 32 count: 19
kdevplatform.language: item index out of bounds: 30 count: 19
kdevplatform.language: item index out of bounds: 29 count: 19
kdevplatform.language: item index out of bounds: 27 count: 19
kdevplatform.language: item index out of bounds: 26 count: 19
kdevplatform.language: item index out of bounds: 24 count: 19
kdevplatform.language: item index out of bounds: 23 count: 19
kdevplatform.language: item index out of bounds: 21 count: 19
kdevplatform.language: item index out of bounds: 20 count: 19
kdevplatform.language: item index out of bounds: 91 count: 0
kdevplatform.language: item index out of bounds: 90 count: 0
kdevplatform.language: item index out of bounds: 88 

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #39 from RJVB  ---
Just wondering, when in my patch I bail out from an otherwise endless loop and
thus leave at least 1 entry undeleted, do those get deleted at runtime in a
future session? Or do they risk ending up hanging around because attempts to
delete them are only made on exit and my workaround is always triggered then?

Judging from diag. output the latter would seem more likely, which makes me
wonder if one couldn't queue a clean-up phase after loading a session (i.e.
when all language support plugins are loaded)?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Thomas Schöps]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #38 from Thomas Schöps  ---
Yes, I could imagine that there are such problems and the procedure that you
describe might be better. But I am not knowledgeable enough about the KDevelop
architecture to make any well-informed decisions here. What I can tell is that
my workaround "works for me" (TM), at least I haven't seen related issues since
I started using it, and thus I proposed a merge request for it now since it
appears that it at least improves over the current situation:

https://invent.kde.org/kde/kdevelop/merge_requests/61

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #37 from RJVB  ---
Couldn't there be a chicken-and-egg situation here? I wouldn't be surprised if
certain plugins need DUchain to be present & working, and wouldn't a reliable
shutdown procedure look something like the following?

- tell plugins to clean up in preparation for unloading
...
- tell DUchain to clean up in preparation for shutdown
...
- unload plugins
...
- shutdown DUchain

DUchain is so central that its final demise could (almost) be part of the
global destruction phase.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Thomas Schöps]

https://bugs.kde.org/show_bug.cgi?id=379669

Thomas Schöps  changed:

   What|Removed |Added

 CC||tom.scho...@gmail.com

--- Comment #36 from Thomas Schöps  ---
Contrary to a previous comment, I have the impression that the language plugins
may be unloaded before the final DUChain cleanup: see
https://invent.kde.org/kde/kdevelop/blob/master/kdevplatform/shell/core.cpp#L429
, where I think that d->pluginController->cleanup(); will cause the plugins to
be unloaded, while the DUChain shutdown only happens a few lines below.

Thus I currently test the following change in an attempt to fix the bug
reported here:

index 19146ba42d..417b4f7e7f 100644
@@ -428,2 +428,6 @@ void Core::cleanup()
 d->languageController->backgroundParser()->waitForIdle();
+
+DUChain::self()->shutdown();
+
+// Only unload plugins after the DUChain shutdown to prevent issues
with non-loaded factories for types
 d->pluginController->cleanup();
@@ -436,4 +440,2 @@ void Core::cleanup()
 d->languageController->cleanup();
-
-DUChain::self()->shutdown();
 }


So far, I didn't encounter the bug with this change applied, but since it only
happened occasionally, this doesn't necessarily mean that it is fixed. Also,
since I am not familiar with the overall KDevelop architecture, I don't know
whether this change in shutdown order may introduce subtle issues that I am not
aware of. So far, I haven't noticed issues.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Aleksey Midenkov]

https://bugs.kde.org/show_bug.cgi?id=379669

Aleksey Midenkov  changed:

   What|Removed |Added

 CC||midenok+kdeb...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

RJVB  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=379004

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #35 from RJVB  ---
Created attachment 121377
  --> https://bugs.kde.org/attachment.cgi?id=121377=edit
June 2019 version of the workaround patch

I've been maintaining the patch and adding the occasional tweak to it to catch
newly identified related issues and/or generate potentially useful trace
output.

I don't think I've experienced a hang for quite some time now, just the
occasional crash in libclang (which is not due to a bug in KDevelop AFAICT).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

RJVB  changed:

   What|Removed |Added

 Attachment #113627|latest version of the   |June 2018 version of the
description|workaround patch|workaround patch

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #34 from RJVB  ---
Created attachment 116580
  --> https://bugs.kde.org/attachment.cgi?id=116580=edit
terminal log

Here's a log showing an exceptionally large number of caught issues where a
hang would have resulted during the global destruction phase. There's
redundancy, I haven't checked if the warning for all items is printed 4x
(corresponding to as many attempts to delete them).

Interestingly, the Bucket::deleteItem warning list is exactly identical across
restarts, and doesn't even depend on whether I load the projects via the CMake
server or force them to load via the legacy compile_commands-based importer
(which is still about 5x faster for this configuration!).

This session has 2 projects open from the same directory of kdevelop sources,
patched with my change to build the IDE and the clang-parser separately. Each
project has its own build dir, evidently, and the clang-parser project has
filters for almost everything but the plugins/clang directory.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #33 from RJVB  ---
FWIW, I haven't seen hangs in a while with my workaround patch applied. Debug
output showing that hang situations were handled appears quite regularly
though.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Kevin Funk]

https://bugs.kde.org/show_bug.cgi?id=379669

Kevin Funk  changed:

   What|Removed |Added

 CC||ricardo@hotmail.com

--- Comment #32 from Kevin Funk  ---
*** Bug 401211 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[David Nolden]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #31 from David Nolden  ---
Could you check whether the python plugin (both of its components) are
loaded/unloaded before the crash happens? (you could do it with the patch I
attached)

For me, the python language supports are always unloaded _after_ the final
duchain cleanup is done.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[David Nolden]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #30 from David Nolden  ---
Created attachment 114532
  --> https://bugs.kde.org/attachment.cgi?id=114532=edit
Patch to debug loading/unloading of python plugin

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #29 from RJVB  ---
Created attachment 114422
  --> https://bugs.kde.org/attachment.cgi?id=114422=edit
example on-exit terminal output with the "AlwaysEnable" patch

I saw that setting AlwaysEnabled also makes a plugin "ununloadable" ... but
apparently it doesn't make a difference here. Those early returns thanks to my
patch would be space heater hangs otherwise.

This output is reproducible (details may vary though), and occurs whether or
not ilanguage plugins are made AlwaysEnabled.

The session contains projects for ECM, kwidgetsaddons, kwindowsystem, KIO and
qqc2-desktop-style, but only has .cpp, .h and CMake files open.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #28 from RJVB  ---
No guarantees I'll get around to that the next 2 weeks (and even less so that
I'd get the issue during that time!)

BTW, how is this supposed to help if the issue is caused by unloading plugins
too early? Doesn't that mean they were loaded at some point, regardless whether
AlwaysEnabled was set or not?
(If anything I could imagine that loading more plugins only increases the
chance that some plugin is unloaded with outstanding references to it?!)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[David Nolden]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #27 from David Nolden  ---
Created attachment 114420
  --> https://bugs.kde.org/attachment.cgi?id=114420=edit
Hack setting all language-support plugins to AlwaysOn

Can you try if this hack works for you? (I'm testing it now, but I'm not sure
if it achieves the correct effect)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[David Nolden]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #26 from David Nolden  ---
These are not "language IDs", but rather "item IDs", and the mapping from
identity to a factory (and thus to a language plugin) only exists when the
plugin is loaded. Otherwise these are just unknown items.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[David Nolden]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #24 from David Nolden  ---
I've checked the identities, and all the duchain item identities that you
mentioned before belong to the kdev-python plugin, so my guess is now that the
kdev-python plugin was unloaded.

I've further thought about the problem, and I think that these measures are
necessary to solve this properly:

1. We should never unload language plugins. We can unregister them from the UI,
but the shared library should not actually be unloaded. It is not safe to do
it, because special types/declarations/contexts defined in this language plugin
may still be in the shorted lived duchain cache, and the on-disk duchain cache
may contain items for from this plugin that need to be cleaned/deleted.

2. While doing any duchain operations (like cleanup), we have to make sure that
the corresponding language plugins are loaded whenever touching a certain item.
E.g. when a top-context for kdev-python is loaded, we have to make sure that
the plugin is loaded before that. This is practically not a problem at the
moment though, because these items are usually loaded when a corresponding file
is opened in the editor, and therefore, the language plugin is available.
However, at least theoretically, this could be a problem during certain cleanup
operations.

In the long term, it would probably be best to put the duchain specific parts
of language plugins into separate libraries, and statically preload these at
KDevelop startup, and unload them during shutdown, but don't do any dynamic
loading/unloading on them at runtime.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #23 from RJVB  ---
> Maybe your other crashes with "project unloading" were also related to 
> unloaded language plugins. Which language plugins do you use?

Possibly, but I cannot remember if I had any "interesting" terminal output at
the time and haven't seen them for a while (thanks to my patch?). The big
problem with this issue is that it appears to happen at random (the timeouts in
certain operations may be responsible for that). That makes debugging it so
tricky (and you really need to build without any optimisation, which is not an
option for me for everyday use - which is how I use KDevelop...)
I mostly work with C, C++ and ObjC(++) files, CMake files and the occasional
Python file. But I've never taken stock exactly which language plugins get
installed with KDevelop.

I have a hunch (but no proof) that the dangling data that remains is only a
single item at the time, not a whole tree, so the impact on subsequent sessions
could be negligible. But I guess that impact could be made 0 by marking the
duchain cache as dirty if the cleanup knowingly leaves dangling data, so that
the whole cache gets rebuild during the next startup?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[David Nolden]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #22 from David Nolden  ---
The reason why it helps is probably because it simply avoids the recursive
destruction and data reclaim mechanisms. And if the data ranges are not put
into the "free list", they will never be touched again and also not cause many
problems, they will just stay sitting there consuming space and memory.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[David Nolden]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #21 from David Nolden  ---
I'm not saying what you're doing is bad, but it's probably not the most
sustainable way to fix it. For example, this may leave unclaimed data in the
duchain disk cache which will also consume memory in succeeding KDevelop runs,
that can maybe never be reclaimed until the cache is cleared completely (which
we usually do only after crashes).

Maybe your other crashes with "project unloading" were also related to unloaded
language plugins. Which language plugins do you use?

Maybe a viable solution would be to generally avoid physically unloading
language support plugins, because that may leave dangling data in the duchain
cache which can not be handled any more during cleanup.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[David Nolden]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #20 from David Nolden  ---
Doing cleanup much earlier, e.g. in aboutToQuit, would probably be difficult,
because you need to make sure that no duchain data structures (e.g.
IndexedString) are accessed after that. All parsing must be finished, no
"editor highlighting" or "code-completion" events queued in the event queue,
etc.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #19 from RJVB  ---
>From memory, my patch mostly introduces common-sense error handling, it doesn't
change anything else in the hash internals. I don't understand those, so I keep
my hands off. I don't even understand why my attempts at handling deviant
situations gracefully actually work instead of just moving the location of the
crash, but it's a fact that they do.

I won't claim it's a fix, provided you can prove that the situations currently
not being handled can be avoided with 100% reliability. But if you can't prove
that then it's more than a workaround and IMHO a fix for the crashes and hangs
I've been seeing.
And in that light it makes a whole lot more sense than just letting the code
crash (regardless whether through an abort or after doing something with
potential side-effects). Call it a necessary and hopefully temporary evil if
you will, at least for production builds where all those Q_ASSERT checks become
no-ops. As a user of a supposedly serious productivity tool I'm usually not
interested in getting random aborts in order to help iron out a poorly
understood glitch somewhere: the code should make reasonable attempts to
recover from such a glitch if that is in anyway possible.

IIRC I have also observed crashes at runtime, possibly (probably) when
unloading projects.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[David Nolden]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #18 from David Nolden  ---
Btw. the cleanup is mainly concerning the on-disk cache structure.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[David Nolden]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #17 from David Nolden  ---
It doesn't make sense to fiddle around with the internals of the hash, when
this only happens during shutdown.

The question is what's different during shutdown than during the earlier
cleanup calls.

The last message by RJVB might indicate the problem. "deleteBucket" requires
the types of items to be registered, so that it can call destructors (and
eventually also delete other items referenced recursively). It seems that for
some types, the factories are not registered. Maybe the problem is that some
language plugin, which had some declared some types (what are 62 and 63?) was
already unloaded and the factory unregistered. In that case, it would be
necessary to make sure that the cleanup is called earlier, before any plugins
are unloaded.

By the way, it might also be a viable option to completely skip the final
cleanup during shutdown. It updates the disk duchain cache, but the earlier
cleanups that happen during runtime also update the disk cache, so the cache
data loss would be bearable (depending on the duchain cleanup interval).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Raúl]

https://bugs.kde.org/show_bug.cgi?id=379669

Raúl  changed:

   What|Removed |Added

 CC||rasas...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

RJVB  changed:

   What|Removed |Added

 Attachment #105591|0   |1
is obsolete||

--- Comment #16 from RJVB  ---
Created attachment 113627
  --> https://bugs.kde.org/attachment.cgi?id=113627=edit
latest version of the workaround patch

This version catches a few additional hangs and crashes

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #15 from RJVB  ---
I now have a session that will print a huge list of debug messages
systematically at exit, from one of the places where I added anti-hang
protections. Always about types 62 and 63, plus a few type 59 and 64 at the
beginning.
Not deleting the items doesn't seem to have any impact AFAICT, why not just
skip this step at exit - aren't the days over where not freeing RAM meant it
was lost until the next reboot?

kdevplatform.language: Factory for this type not loaded: 63
"Bucket::deleteItem(15816,1420266610,Type Repository)" : early return because
currentIndex==0
didn't delete item of size 36
kdevplatform.language: Factory for this type not loaded: 63
"Bucket::deleteItem(1024,1420266610,Type Repository)" : early return because
currentIndex==0
didn't delete item of size 36
kdevplatform.language: Factory for this type not loaded: 62
"Bucket::deleteItem(914,1420266610,Type Repository)" : early return because
currentIndex==0
didn't delete item of size 36
kdevplatform.language: Factory for this type not loaded: 62
"Bucket::deleteItem(12882,1420266610,Type Repository)" : early return because
currentIndex==0
didn't delete item of size 36
kdevplatform.language: Factory for this type not loaded: 62
"Bucket::deleteItem(8216,1420266610,Type Repository)" : early return because
currentIndex==0
didn't delete item of size 36
kdevplatform.language: Factory for this type not loaded: 62
"Bucket::deleteItem(4680,1420266610,Type Repository)" : early return because
currentIndex==0
didn't delete item of size 36
kdevplatform.language: Factory for this type not loaded: 62
"Bucket::deleteItem(16418,1420266610,Type Repository)" : early return because
currentIndex==0
didn't delete item of size 36
kdevplatform.language: Factory for this type not loaded: 63
"Bucket::deleteItem(8326,1420266610,Type Repository)" : early return because
currentIndex==0
didn't delete item of size 36

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #14 from RJVB  ---
I just had another of these fits, in the 5.2 branch (and not running that patch
of mine AFAIK):

* thread #1: tid = 0x1a89e11, 0x00010a28f93a
libKDevPlatformLanguage.10.dylib`void
KDevelop::Bucket::deleteItem
>(this=0x7fb569184f80, index=38574, hash=,
repository=) + 298 at itemrepository.h:547, queue =
'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00010a28f93a libKDevPlatformLanguage.10.dylib`void
KDevelop::Bucket::deleteItem
>(this=0x7fb569184f80, index=38574, hash=,
repository=) + 298 at itemrepository.h:547
frame #1: 0x00010a28efe8 libKDevPlatformLanguage.10.dylib`int
KDevelop::Bucket::finalCleanup
>(this=0x7fb569184f80, repository=0x000117c59000) + 184 at
itemrepository.h:681
frame #2: 0x00010a28e9df
libKDevPlatformLanguage.10.dylib`KDevelop::ItemRepository::finalCleanup(this=0x000117c59000) + 111 at itemrepository.h:2078
frame #3: 0x00010b2d1d3d
libKDevPlatformSerialization.10.dylib`KDevelop::ItemRepositoryRegistry::finalCleanup(this=)
+ 173 at itemrepositoryregistry.cpp:369
frame #4: 0x00010a1d300d
libKDevPlatformLanguage.10.dylib`KDevelop::DUChain::shutdown() [inlined]
KDevelop::finalCleanup() + 236 at duchain.cpp:1572
frame #5: 0x00010a1d2f21
libKDevPlatformLanguage.10.dylib`KDevelop::DUChain::shutdown(this=)
+ 433 at duchain.cpp:1610
frame #6: 0x000106ca4671
libKDevPlatformShell.10.dylib`KDevelop::Core::cleanup(this=0x7fb565816f20)
+ 705 at core.cpp:440
frame #7: 0x000106ca405b
libKDevPlatformShell.10.dylib`KDevelop::Core::shutdown(this=0x7fb565816f20)
+ 107 at core.cpp:387
frame #8: 0x000109ac3fab QtCore`QMetaObject::activate(QObject*, int,
int, void**) [inlined] QtPrivate::QSlotObjectBase::call(this=,
r=, a=) + 2011 at qobject_impl.h:101
frame #9: 0x000109ac3f8f
QtCore`QMetaObject::activate(sender=0x7fff59155e60,
signalOffset=, local_signal_index=,
argv=) + 1983 at qobject.cpp:3728
frame #10: 0x000109a93e32 QtCore`QCoreApplication::exec() [inlined]
QCoreApplicationPrivate::q_func(this=) + 402 at
qcoreapplication_p.h:72
frame #11: 0x000109a93e29 QtCore`QCoreApplication::exec() [inlined]
QCoreApplicationPrivate::execCleanup(this=,
this=0x7fb563416070) + 24 at qcoreapplication.cpp:1288
frame #12: 0x000109a93e11 QtCore`QCoreApplication::exec() + 369 at
qcoreapplication.cpp:1272
frame #13: 0x000106ac2766 kdevelop.bin`main(argc=,
argv=0x7fff591560b0) + 52438 at main.cpp:917
frame #14: 0x7fff906e25fd libdyld.dylib`start + 1

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Kevin Funk]

https://bugs.kde.org/show_bug.cgi?id=379669

Kevin Funk  changed:

   What|Removed |Added

 CC||david.nolden.kde@art-master
   ||.de, m...@milianw.de

--- Comment #13 from Kevin Funk  ---
Confirmed, it's still not fixed. I'd really like this to get fixed *now* but
it's over my head -- I don't understand the root cause.

I'm afraid we'll have to resort using Rene's patch in order to at least fix the
constant hangs-on-exit or CPU churn for our end users...

If someone else from the KDevelop core team could have a look at this issue
that'b appreciated. It's daunting to debug though.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Francis Herne]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #12 from Francis Herne  ---
I just got this hang with 0f101e4c1 (master as of three days ago), so I'm
afraid this doesn't seem fixed yet in all cases.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Kevin Funk]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #11 from Kevin Funk  ---
Git commit 6fb0143838087cc430d95dc406e3f7e684d9d6b9 by Kevin Funk.
Committed on 07/08/2017 at 07:50.
Pushed by kfunk into branch '5.1'.

backgroundparser: Ensure jobs are finished on exit

Summary:
Make sure all parse jobs are done *before* potentially starting to unload
language plugins.
I think this fixes one cause of bug 379669.

With this patch I also fix an assert which I added earlier today; which
triggers when exiting KDevelop:

Log excerpt:
```
kdevelop(21550)/kdevplatform.shell:
KDevelop::PluginController::unloadPlugin(442): unloading plugin:
ManPagePlugin(0x606001ae16c0) "Man Pages"
kdevelop(21550)/kdevplatform.documentation:
DocumentationView::showDocumentation(187): showing "CMake Content Page"
kdevelop(21550)/kdevplatform.language:
KDevelop::TypeSystem::ensureFactoryLoaded(64): Factory for this type not
loaded: 18
kdevelop(21550)/default: unknown(0): ASSERT: "false" in file
/home/kfunk/devel/src/kf5/kdevplatform-stable/language/duchain/types/typeregister.cpp,
line 65
```

Subscribers: brauch, kdevelop-devel

Differential Revision: https://phabricator.kde.org/D7128

M  +25   -0language/backgroundparser/backgroundparser.cpp
M  +2-0language/backgroundparser/backgroundparser.h
M  +5-1shell/core.cpp

https://commits.kde.org/kdevplatform/6fb0143838087cc430d95dc406e3f7e684d9d6b9

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #10 from RJVB  ---
FWIW, I haven't seen the hang since applying your patch (but I'm not sure we
can cry victory yet, the issue was always highly unpredictable).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Kevin Funk]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #9 from Kevin Funk  ---
Git commit 0714e5d52abedbf73cebab5986905a3841b68449 by Kevin Funk.
Committed on 04/08/2017 at 08:46.
Pushed by kfunk into branch '5.1'.

TypeRegister: Stronger assumptions in debug mode

All of these should hold at all times

M  +21   -4language/duchain/types/typeregister.cpp
M  +2-0language/duchain/types/typeregister.h

https://commits.kde.org/kdevplatform/0714e5d52abedbf73cebab5986905a3841b68449

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

RJVB  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=382100

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #8 from RJVB  ---
FWIW, even when this hang doesn't occur KDevelop can take forever to shutdown.
The other day I had the source trees for GCC 6.3.0 and 7.1.0 open in respective
projects in a single session. I'm not suicidal: I configure my sessions NOT to
parse the entire project upon opening it, and I had only 2 small files open per
project.
I killed the session after letting it try to exit for a few hours. I *think* it
wasn't caught in a deadloop because the active thread count fluctuated but my
debugger ran out of memory when I tried to attach it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Francis Herne]

https://bugs.kde.org/show_bug.cgi?id=379669

Francis Herne  changed:

   What|Removed |Added

 CC||m...@flherne.uk

--- Comment #7 from Francis Herne  ---
This frequently happens for me with 5.1, KDevelop continuously pegs one CPU
core even after exiting.

It's a serious problem when using a laptop on battery power, I have to manually
kill the offending process or just use Kate. Posted a few backtraces on IRC a
while ago, kfunk confirms it's the same issue.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #6 from RJVB  ---
Is there any chance this and #379977 could somehow be related? The "easy"
explanation would be if another thread (or 2) were locked in a never-ending
wait to get a duchain lock but I don't see any evidence of that in the
backtrace here.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

RJVB  changed:

   What|Removed |Added

 Attachment #105432|0   |1
is obsolete||

--- Comment #5 from RJVB  ---
Created attachment 105591
  --> https://bugs.kde.org/attachment.cgi?id=105591=edit
my current test patch

This elaborates on the previous versions by shadowing m_dirty during the
finalCleanup call. IIUC, that flag indicates whether the repository was dirtied
since the last call to finalCleanup (final? :)) . Ensuring that nothing can
touch that flag while finalCleanup runs seems thus a constructive idea.

Also, don't break out of the inner loop if Bucket::deleteItem bails out early.

Either the two changes might have prevented my latest hang where deleteItem was
called repeatedly with the same index and item hash from the Type repository.

A thought: could those unexpected items represent stale items that weren't
removed properly? Is there a way to know what the item is/was at this location?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

RJVB  changed:

   What|Removed |Added

 Attachment #105430|0   |1
is obsolete||

--- Comment #4 from RJVB  ---
Created attachment 105432
  --> https://bugs.kde.org/attachment.cgi?id=105432=edit
my current test patch

It didn't take long to catch a deadloop, despite the early return. I think
that's probably because the calling finalCleanup() function doesn't check for
duplicate indices either and just keeps calling Bucket::deleteItem() with the
same index.

On a side-note: I also had a runtime hang, in duchain.cpp while trying to get a
lock. I got out of that one by attaching a debugger and setting a non-zero
timeout. Maybe a thought, using a "very long" timeout by default (if this
starts happening more often)?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #3 from RJVB  ---
Created attachment 105430
  --> https://bugs.kde.org/attachment.cgi?id=105430=edit
my current test patch

Good to see this confirmed and bumped to a higher priority.

I've attached the patch I'm currently running (since creating this ticket) in
hope of finding at least an acceptable way to avoid hanging in production
builds.

I noticed that the check I once had against the most obvious dead-looping
situation (currentIndex == previousIndex) had gone missing so I've
re-introduced it. No idea if returning instead of aborting is an appropriate
way to handle this kind of unexpected situations but it's probably no worse
than NOT returning and continuing execution as if the assert wouldn't have
failed :)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Kevin Funk]

https://bugs.kde.org/show_bug.cgi?id=379669

Kevin Funk  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Priority|NOR |HI
 Status|UNCONFIRMED |CONFIRMED

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]

[Kevin Funk]

https://bugs.kde.org/show_bug.cgi?id=379669

Kevin Funk  changed:

   What|Removed |Added

Summary|KDevelop continues to hang  |KDevelop continues to hang
   |on exit in itemrepository.h |on exit in itemrepository.h
   ||[Bucket::deleteItem]

-- 
You are receiving this mail because:
You are watching all bug changes.