Bug 379669

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

Something else: do the low-level methods that are being called have to be in the `itemrepository.h` *header*? Testing different things would be easier if it didn't require/cause such large-scale rebuilds.

Created attachment 105430 [details]
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 :)

Created attachment 105432 [details]
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)?

Created attachment 105591 [details]
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?

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.

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.

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.

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   -4    language/duchain/types/typeregister.cpp
M  +2    -0    language/duchain/types/typeregister.h

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

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).

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   -0    language/backgroundparser/backgroundparser.cpp
M  +2    -0    language/backgroundparser/backgroundparser.h
M  +5    -1    shell/core.cpp

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

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.

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.

I just had another of these fits, in the 5.2 branch (and not running that patch of mine AFAIK):

* thread #1: tid = 0x1a89e11, 0x000000010a28f93a libKDevPlatformLanguage.10.dylib`void KDevelop::Bucket<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, 0u>::deleteItem<KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u> >(this=0x00007fb569184f80, index=38574, hash=<unavailable>, repository=<unavailable>) + 298 at itemrepository.h:547, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x000000010a28f93a libKDevPlatformLanguage.10.dylib`void KDevelop::Bucket<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, 0u>::deleteItem<KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u> >(this=0x00007fb569184f80, index=38574, hash=<unavailable>, repository=<unavailable>) + 298 at itemrepository.h:547
    frame #1: 0x000000010a28efe8 libKDevPlatformLanguage.10.dylib`int KDevelop::Bucket<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, 0u>::finalCleanup<KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u> >(this=0x00007fb569184f80, repository=0x0000000117c59000) + 184 at itemrepository.h:681
    frame #2: 0x000000010a28e9df libKDevPlatformLanguage.10.dylib`KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u>::finalCleanup(this=0x0000000117c59000) + 111 at itemrepository.h:2078
    frame #3: 0x000000010b2d1d3d libKDevPlatformSerialization.10.dylib`KDevelop::ItemRepositoryRegistry::finalCleanup(this=<unavailable>) + 173 at itemrepositoryregistry.cpp:369
    frame #4: 0x000000010a1d300d libKDevPlatformLanguage.10.dylib`KDevelop::DUChain::shutdown() [inlined] KDevelop::finalCleanup() + 236 at duchain.cpp:1572
    frame #5: 0x000000010a1d2f21 libKDevPlatformLanguage.10.dylib`KDevelop::DUChain::shutdown(this=<unavailable>) + 433 at duchain.cpp:1610
    frame #6: 0x0000000106ca4671 libKDevPlatformShell.10.dylib`KDevelop::Core::cleanup(this=0x00007fb565816f20) + 705 at core.cpp:440
    frame #7: 0x0000000106ca405b libKDevPlatformShell.10.dylib`KDevelop::Core::shutdown(this=0x00007fb565816f20) + 107 at core.cpp:387
    frame #8: 0x0000000109ac3fab QtCore`QMetaObject::activate(QObject*, int, int, void**) [inlined] QtPrivate::QSlotObjectBase::call(this=<unavailable>, r=<unavailable>, a=<unavailable>) + 2011 at qobject_impl.h:101
    frame #9: 0x0000000109ac3f8f QtCore`QMetaObject::activate(sender=0x00007fff59155e60, signalOffset=<unavailable>, local_signal_index=<unavailable>, argv=<unavailable>) + 1983 at qobject.cpp:3728
    frame #10: 0x0000000109a93e32 QtCore`QCoreApplication::exec() [inlined] QCoreApplicationPrivate::q_func(this=<unavailable>) + 402 at qcoreapplication_p.h:72
    frame #11: 0x0000000109a93e29 QtCore`QCoreApplication::exec() [inlined] QCoreApplicationPrivate::execCleanup(this=<unavailable>, this=0x00007fb563416070) + 24 at qcoreapplication.cpp:1288
    frame #12: 0x0000000109a93e11 QtCore`QCoreApplication::exec() + 369 at qcoreapplication.cpp:1272
    frame #13: 0x0000000106ac2766 kdevelop.bin`main(argc=<unavailable>, argv=0x00007fff591560b0) + 52438 at main.cpp:917
    frame #14: 0x00007fff906e25fd libdyld.dylib`start + 1

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

Created attachment 113627 [details]
June 2018 version of the workaround patch

This version catches a few additional hangs and crashes

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).

Btw. the cleanup is mainly concerning the on-disk cache structure.

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.

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.

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.

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.

> 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?

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.

I wouldn't be surprised if kdev-python were involved (if not only because I don't update it very often, nor do I usually rebuild/reinstall after KDevelop upgrades - I guess I'm not the only one in that position?).

FWIW (and this links to your point 2) I don't always have kdev-python loaded, esp. not in session for the KDevelop sources, and that's the one where I get the crash/hang most often.

FWIW2: Qt itself has stopped unloading most plugins on exit a few releases ago, exactly because it's almost impossible to guarantee that no race-conditions will occur (for generic plugins). But will not unloading language plugins guarantee that none of the various situations my patch handles will occur?
Also, if this indeed happens only with unloaded language plugins, does each repository item know which plugin it goes with? If so, wouldn't it be possible and maybe preferable to maintain a table of loaded plugins that registers when they've been unloaded, and then skip items that go with an unloaded plugin?

FWIW3: it'd be very useful if error messages printed the language instead of the language ID
```
kdevplatform.language: Cannot load a top-context from store "/home/bertin/.cache/kdevduchain/kdevelop-{f793a513-f14e-47b9-8448-06ca72900c04}/topcontexts/data.mdb:#3619" - the required language-support for handling ID 110 is probably not loaded
```

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.

Created attachment 114420 [details]
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)

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?!)

Created attachment 114422 [details]
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.

Created attachment 114532 [details]
Patch to debug loading/unloading of python plugin

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.

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

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.

Created attachment 116580 [details]
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.

Created attachment 121377 [details]
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).

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.

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.

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

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)?

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  0x00007f9d947a5f35 in KDevelop::Bucket<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, 0u>::deleteItem<KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u> >(unsigned short, unsigned int, KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u>&)
    (repository=..., hash=<optimized out>, index=62268, this=0x7f9d380051f0) at ./kdevplatform/serialization/itemrepository.h:972
#1  0x00007f9d947a5f35 in KDevelop::Bucket<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, 0u>::finalCleanup<KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u> >(KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u>&) (repository=..., this=<optimized out>)
    at ./kdevplatform/serialization/itemrepository.h:696
#2  0x00007f9d947a5f35 in KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u>::finalCleanup() (this=<optimized out>) at ./kdevplatform/serialization/itemrepository.h:2195
#3  0x00007f9d942b6999 in KDevelop::ItemRepositoryRegistry::finalCleanup() (this=<optimized out>)
    at ./kdevplatform/serialization/itemrepositoryregistry.cpp:383
#4  0x00007f9d946de41a in KDevelop::finalCleanup () at ./kdevplatform/language/duchain/duchain.cpp:1704
#5  0x00007f9d946de41a in KDevelop::DUChain::shutdown() (this=<optimized out>) at ./kdevplatform/language/duchain/duchain.cpp:1742
#6  0x00007f9d972ae646 in KDevelop::Core::cleanup() (this=0x55df81dbc9c0) at ./kdevplatform/shell/core.cpp:431
#7  0x00007f9d972ae8dc in KDevelop::Core::shutdown() (this=0x55df81dbc9c0) at ./kdevplatform/shell/core.cpp:386
#8  0x00007f9d9728da5d in KDevelop::MainWindow::~MainWindow() (this=this@entry=0x55df81eebbc0, __in_chrg=<optimized out>, __vtt_parm=<optimized out>)
    at ./kdevplatform/shell/mainwindow.cpp:150
#9  0x00007f9d9728dab9 in KDevelop::MainWindow::~MainWindow() (this=0x55df81eebbc0, __in_chrg=<optimized out>, __vtt_parm=<optimized out>)
    at ./kdevplatform/shell/mainwindow.cpp:146
#10 0x00007f9d95c9e100 in QObject::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007f9d9681b96b in QWidget::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
--Type <RET> for more, q to quit, c to continue without paging--
#12 0x00007f9d96921d64 in QMainWindow::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#13 0x00007f9d93da717b in KMainWindow::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#14 0x00007f9d93df1115 in KXmlGuiWindow::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#15 0x00007f9d967dd4c1 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x00007f9d967e4970 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x00007f9d95c744f9 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x00007f9d95c774db in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x00007f9d95cc6173 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x00007f9d9228ef2e in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007f9d9228f1c8 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x00007f9d9228f25c in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x00007f9d95cc5797 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x00007f9d88398401 in  () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#25 0x00007f9d95c731cb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#26 0x00007f9d95c7b1a2 in QCoreApplication::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#27 0x000055df81b253ac in main(int, char**) (argc=<optimized out>, argv=<optimized out>) 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 count: 0
kdevplatform.language: item index out of bounds: 87 count: 0
kdevplatform.language: item index out of bounds: 83 count: 0
kdevplatform.language: item index out of bounds: 82 count: 0
kdevplatform.language: item index out of bounds: 80 count: 0
kdevplatform.language: item index out of bounds: 79 count: 0
kdevplatform.language: item index out of bounds: 77 count: 0
kdevplatform.language: item index out of bounds: 76 count: 0
kdevplatform.language: item index out of bounds: 74 count: 0
kdevplatform.language: item index out of bounds: 73 count: 0
kdevplatform.language: item index out of bounds: 69 count: 0
kdevplatform.language: item index out of bounds: 68 count: 0
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kdevelop path = /usr/bin pid = 10977
KCrash: Arguments: /usr/bin/kdevelop 
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from kdeinit
sock_file=/run/user/1000/kdeinit5__0
QSocketNotifier: Invalid socket 6 and type 'Read', disabling...
QSocketNotifier: Invalid socket 97 and type 'Read', disabling...
QSocketNotifier: Invalid socket 117 and type 'Read', disabling...
QSocketNotifier: Invalid socket 19 and type 'Read', disabling...
QSocketNotifier: Invalid socket 50 and type 'Read', disabling...
QSocketNotifier: Invalid socket 116 and type 'Read', disabling...
QSocketNotifier: Invalid socket 99 and type 'Read', disabling...
QSocketNotifier: Invalid socket 126 and type 'Read', disabling...
QSocketNotifier: Invalid socket 10 and type 'Read', disabling...
QSocketNotifier: Invalid socket 119 and type 'Exception', disabling...
QSocketNotifier: Invalid socket 102 and type 'Read', disabling...
QSocketNotifier: Invalid socket 121 and type 'Read', disabling...
QSocketNotifier: Invalid socket 133 and type 'Read', disabling...
QSocketNotifier: Invalid socket 122 and type 'Read', disabling...
QSocketNotifier: Invalid socket 130 and type 'Read', disabling...
QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
QSocketNotifier: Invalid socket 45 and type 'Read', disabling...
QSocketNotifier: Invalid socket 9 and type 'Read', disabling...
QSocketNotifier: Invalid socket 134 and type 'Read', disabling...
The X11 connection broke (error 1). Did the X11 server die?

Created attachment 127166 [details]
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.

  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  0x00007f8bf8da73ff in __GI___poll (fds=0x7f8b3809e7a0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f8bf5aa50ae in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f8bf5aa51cf in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f8bf934d4bf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f8b384bbe70, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#4  0x00007f8bf92f492b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7f8b60f8fbe0, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#5  0x00007f8bf9113a3e in QThread::exec() (this=<optimized out>) at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#6  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x55d9c4a66c20) at thread/qthread_unix.cpp:329
#7  0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#8  0x00007f8bf8db1def 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  0x00007f8bf911aafb in QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., deadline=..., this=0x55d9c2f81320) at thread/qwaitcondition_unix.cpp:146
#4  QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=<optimized out>, mutex=0x55d9c30018c0, deadline=...) at thread/qwaitcondition_unix.cpp:225
#5  0x00007f8bf5a3d214 in ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned(ThreadWeaver::Thread*) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x00007f8bf5a41d8e in  () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x00007f8bf5a3d0f2 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x00007f8bf5a3f670 in ThreadWeaver::Thread::run() () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#9  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x7f8b5c004e10) at thread/qthread_unix.cpp:329
#10 0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#11 0x00007f8bf8db1def 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  0x00007f8bf911aafb in QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., deadline=..., this=0x55d9c2f81320) at thread/qwaitcondition_unix.cpp:146
#4  QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=<optimized out>, mutex=0x55d9c30018c0, deadline=...) at thread/qwaitcondition_unix.cpp:225
--Type <RET> for more, q to quit, c to continue without paging--c
#5  0x00007f8bf5a3d214 in ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned(ThreadWeaver::Thread*) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x00007f8bf5a41d8e in  () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x00007f8bf5a3d0f2 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x00007f8bf5a3f670 in ThreadWeaver::Thread::run() () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#9  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x7f8b680051f0) at thread/qthread_unix.cpp:329
#10 0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#11 0x00007f8bf8db1def 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  0x00007f8bf911aafb in QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., deadline=..., this=0x55d9c2f81320) at thread/qwaitcondition_unix.cpp:146
#4  QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=<optimized out>, mutex=0x55d9c30018c0, deadline=...) at thread/qwaitcondition_unix.cpp:225
#5  0x00007f8bf5a3d214 in ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned(ThreadWeaver::Thread*) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x00007f8bf5a41d8e in  () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x00007f8bf5a3d0f2 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x00007f8bf5a3f670 in ThreadWeaver::Thread::run() () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#9  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x7f8b640045e0) at thread/qthread_unix.cpp:329
#10 0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#11 0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 19 (Thread 0x7f8b7e7fc700 (LWP 3634) "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  0x00007f8bf911aafb in QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., deadline=..., this=0x55d9c2f81320) at thread/qwaitcondition_unix.cpp:146
#4  QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=<optimized out>, mutex=0x55d9c30018c0, deadline=...) at thread/qwaitcondition_unix.cpp:225
#5  0x00007f8bf5a3d214 in ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned(ThreadWeaver::Thread*) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x00007f8bf5a41d8e in  () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x00007f8bf5a3d0f2 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x00007f8bf5a3f670 in ThreadWeaver::Thread::run() () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#9  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x7f8b70005010) at thread/qthread_unix.cpp:329
#10 0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#11 0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 18 (Thread 0x7f8b7effd700 (LWP 3633) "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  0x00007f8bf911aafb in QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., deadline=..., this=0x55d9c2f81320) at thread/qwaitcondition_unix.cpp:146
#4  QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=<optimized out>, mutex=0x55d9c30018c0, deadline=...) at thread/qwaitcondition_unix.cpp:225
#5  0x00007f8bf5a3d214 in ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned(ThreadWeaver::Thread*) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x00007f8bf5a41d8e in  () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x00007f8bf5a3d0f2 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x00007f8bf5a3f670 in ThreadWeaver::Thread::run() () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#9  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x7f8b6c0051f0) at thread/qthread_unix.cpp:329
#10 0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#11 0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 17 (Thread 0x7f8b7f7fe700 (LWP 3632) "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  0x00007f8bf911aafb in QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., deadline=..., this=0x55d9c2f81320) at thread/qwaitcondition_unix.cpp:146
#4  QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=<optimized out>, mutex=0x55d9c30018c0, deadline=...) at thread/qwaitcondition_unix.cpp:225
#5  0x00007f8bf5a3d214 in ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned(ThreadWeaver::Thread*) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x00007f8bf5a41d8e in  () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x00007f8bf5a3d0f2 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x00007f8bf5a3f670 in ThreadWeaver::Thread::run() () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#9  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x7f8b740041b0) at thread/qthread_unix.cpp:329
#10 0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#11 0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 16 (Thread 0x7f8b7ffff700 (LWP 3631) "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  0x00007f8bf911aafb in QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., deadline=..., this=0x55d9c2f81320) at thread/qwaitcondition_unix.cpp:146
#4  QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=<optimized out>, mutex=0x55d9c30018c0, deadline=...) at thread/qwaitcondition_unix.cpp:225
#5  0x00007f8bf5a3d214 in ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned(ThreadWeaver::Thread*) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x00007f8bf5a41d8e in  () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x00007f8bf5a3d0f2 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x00007f8bf5a41b81 in  () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#9  0x00007f8bf5a3d0f2 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#10 0x00007f8bf5a41b81 in  () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#11 0x00007f8bf5a3d0f2 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#12 0x00007f8bf5a3f670 in ThreadWeaver::Thread::run() () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#13 0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x7f8b780051f0) at thread/qthread_unix.cpp:329
#14 0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#15 0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 15 (Thread 0x7f8b90e62700 (LWP 3630) "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  0x00007f8bf911aafb in QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., deadline=..., this=0x55d9c2f81320) at thread/qwaitcondition_unix.cpp:146
#4  QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=<optimized out>, mutex=0x55d9c30018c0, deadline=...) at thread/qwaitcondition_unix.cpp:225
#5  0x00007f8bf5a3d214 in ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned(ThreadWeaver::Thread*) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x00007f8bf5a41d8e in  () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x00007f8bf5a3d0f2 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x00007f8bf5a3f670 in ThreadWeaver::Thread::run() () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#9  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x7f8b800048e0) at thread/qthread_unix.cpp:329
#10 0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#11 0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 14 (Thread 0x7f8b98976700 (LWP 3629) "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  0x00007f8bf911aafb in QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., deadline=..., this=0x55d9c2f81320) at thread/qwaitcondition_unix.cpp:146
#4  QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=<optimized out>, mutex=0x55d9c30018c0, deadline=...) at thread/qwaitcondition_unix.cpp:225
#5  0x00007f8bf5a3d214 in ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned(ThreadWeaver::Thread*) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x00007f8bf5a41d8e in  () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x00007f8bf5a3d0f2 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x00007f8bf5a3f670 in ThreadWeaver::Thread::run() () at /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#9  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x55d9c37b9ba0) at thread/qthread_unix.cpp:329
#10 0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#11 0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 13 (Thread 0x7f8b9275e700 (LWP 3571) "QQuickXmlQueryE"):
#0  0x00007f8bf8da73ff in __GI___poll (fds=0x7f8b84003730, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f8bf5aa50ae in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f8bf5aa51cf in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f8bf934d4bf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f8b840037e0, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#4  0x00007f8bf92f492b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7f8b9275dbc0, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#5  0x00007f8bf9113a3e in QThread::exec() (this=<optimized out>) at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#6  0x00007f8b912350b5 in  () at /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/XmlListModel/libqmlxmllistmodelplugin.so
#7  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x55d9c50c11b0) at thread/qthread_unix.cpp:329
#8  0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#9  0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 12 (Thread 0x7f8ba4c51700 (LWP 3494) "KDevelop::Compl"):
#0  0x00007f8bf8da73ff in __GI___poll (fds=0x7f8b88005040, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f8bf5aa50ae in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f8bf5aa51cf in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f8bf934d4bf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f8b88000b60, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#4  0x00007f8bf92f492b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7f8ba4c50be0, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#5  0x00007f8bf9113a3e in QThread::exec() (this=<optimized out>) at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#6  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x55d9c373c3f0) at thread/qthread_unix.cpp:329
#7  0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#8  0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 11 (Thread 0x7f8ba5c92700 (LWP 3492) "OutputFilterThr"):
#0  0x00007f8bf8da73ff in __GI___poll (fds=0x7f8b8c005240, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f8bf5aa50ae in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f8bf5aa51cf in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f8bf934d4bf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f8b8c000b60, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#4  0x00007f8bf92f492b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7f8ba5c91be0, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#5  0x00007f8bf9113a3e in QThread::exec() (this=<optimized out>) at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#6  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x7f8bf5977868 <KDevelop::(anonymous namespace)::Q_QGS_s_parsingThread::innerFunction()::holder+8>) at thread/qthread_unix.cpp:329
#7  0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#8  0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 10 (Thread 0x7f8ba7159700 (LWP 3491) "QQmlThread"):
#0  0x00007f8bf8da73ff in __GI___poll (fds=0x7f8b94004a60, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f8bf5aa50ae in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f8bf5aa51cf in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f8bf934d4bf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f8b94000b60, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#4  0x00007f8bf92f492b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7f8ba7158bc0, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#5  0x00007f8bf9113a3e in QThread::exec() (this=<optimized out>) at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#6  0x00007f8bf6a48f85 in  () at /lib/x86_64-linux-gnu/libQt5Qml.so.5
#7  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x55d9c35b4ad0) at thread/qthread_unix.cpp:329
#8  0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#9  0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 9 (Thread 0x7f8bbeffd700 (LWP 3483) "Qt bearer threa"):
#0  0x00007f8bf8da73ff in __GI___poll (fds=0x7f8ba0004a30, nfds=1, timeout=9992) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f8bf5aa50ae in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f8bf5aa51cf in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f8bf934d4bf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f8ba0000b60, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#4  0x00007f8bf92f492b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7f8bbeffcbe0, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#5  0x00007f8bf9113a3e in QThread::exec() (this=<optimized out>) at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#6  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x55d9c2da0320) at thread/qthread_unix.cpp:329
#7  0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#8  0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 8 (Thread 0x7f8bbf7fe700 (LWP 3482) "QThread"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007f8bf9114ea5 in QtLinuxFutex::_q_futex(int*, int, int, unsigned long long, int*, int) (val3=0, addr2=0x0, val2=0, val=3, op=0, addr=0x55d9c2e9c078) at thread/qfutex_p.h:116
#2  QtLinuxFutex::futexWait<QBasicAtomicPointer<QMutexData> >(QBasicAtomicPointer<QMutexData>&, QBasicAtomicPointer<QMutexData>::Type) (expectedValue=0x3, futex=...) at thread/qfutex_p.h:135
#3  lockInternal_helper<false> (timeout=-1, elapsedTimer=0x0, d_ptr=...) at thread/qmutex_linux.cpp:142
#4  QBasicMutex::lockInternal() (this=0x55d9c2e9c078) at thread/qmutex_linux.cpp:159
#5  0x00007f8bf91151a3 in QBasicMutex::lock() (this=0x55d9c2e9c078) at thread/qmutex.h:81
#6  QRecursiveMutexPrivate::lock(int) (this=0x55d9c2e9c060, timeout=timeout@entry=-1) at thread/qmutex.cpp:778
#7  0x00007f8bf9115095 in QMutex::lock() (this=this@entry=0x7f8bf82b4c08 <KDevelop::(anonymous namespace)::Q_QGS_sdDUChainPrivate::innerFunction()::holder+8>) at thread/qmutex.cpp:233
#8  0x00007f8bf7d31e24 in QMutexLocker::QMutexLocker(QBasicMutex*) (m=0x7f8bf82b4c08 <KDevelop::(anonymous namespace)::Q_QGS_sdDUChainPrivate::innerFunction()::holder+8>, this=0x7f8bbf7fd5f8) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmutex.h:233
#9  KDevelop::DUChainPrivate::doMoreCleanup(int, KDevelop::DUChainPrivate::LockFlag) (this=0x7f8bf82b4c00 <KDevelop::(anonymous namespace)::Q_QGS_sdDUChainPrivate::innerFunction()::holder>, retries=1, lockFlag=KDevelop::DUChainPrivate::TryLock) at ./kdevplatform/language/duchain/duchain.cpp:762
#10 0x00007f8bf932c546 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7f8bbf7fd7c0, r=0x7f8bbf7fdbe0, this=0x7f8bac0051f0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#11 doActivate<false>(QObject*, int, void**) (sender=0x7f8bbf7fdbe0, signal_index=3, argv=argv@entry=0x7f8bbf7fd7c0) at kernel/qobject.cpp:3886
#12 0x00007f8bf93258a0 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=<optimized out>, m=m@entry=0x7f8bf958b2a0 <QTimer::staticMetaObject>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7f8bbf7fd7c0) at kernel/qobject.cpp:3946
#13 0x00007f8bf933045a in QTimer::timeout(QTimer::QPrivateSignal) (this=<optimized out>, _t1=...) at .moc/moc_qtimer.cpp:205
#14 0x00007f8bf9321ecf in QObject::event(QEvent*) (this=0x7f8bbf7fdbe0, e=0x7f8bbf7fd930) at kernel/qobject.cpp:1336
#15 0x00007f8bf9f8a15f in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x00007f8bf92f5f6a in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x7f8bbf7fdbe0, event=0x7f8bbf7fd930) at kernel/qcoreapplication.cpp:1063
#17 0x00007f8bf934c883 in QTimerInfoList::activateTimers() (this=0x7f8bac005130) at kernel/qtimerinfo_unix.cpp:643
#18 0x00007f8bf934d104 in timerSourceDispatch(GSource*, GSourceFunc, gpointer) (source=<optimized out>) at kernel/qeventdispatcher_glib.cpp:183
#19 0x00007f8bf5aa4e6b in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007f8bf5aa5118 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007f8bf5aa51cf in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x00007f8bf934d4bf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f8bac000b60, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#23 0x00007f8bf92f492b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7f8bbf7fdb70, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#24 0x00007f8bf9113a3e in QThread::exec() (this=this@entry=0x55d9c2f1ab00) at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#25 0x00007f8bf7d30eac in KDevelop::DUChainPrivate::CleanupThread::run() (this=0x55d9c2f1ab00) at ./kdevplatform/language/duchain/duchain.cpp:331
#26 0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x55d9c2f1ab00) at thread/qthread_unix.cpp:329
#27 0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#28 0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 7 (Thread 0x7f8bd72c1700 (LWP 3477) "kdevelo:disk$3"):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x55d9c2c7a138) at ../sysdeps/nptl/futex-internal.h:186
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55d9c2c7a0e8, cond=0x55d9c2c7a110) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x55d9c2c7a110, mutex=0x55d9c2c7a0e8) at pthread_cond_wait.c:638
#3  0x00007f8bdee833bb in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x00007f8bdee82e87 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#5  0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6  0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 6 (Thread 0x7f8bd7ac2700 (LWP 3476) "kdevelo:disk$2"):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x55d9c2c7a138) at ../sysdeps/nptl/futex-internal.h:186
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55d9c2c7a0e8, cond=0x55d9c2c7a110) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x55d9c2c7a110, mutex=0x55d9c2c7a0e8) at pthread_cond_wait.c:638
#3  0x00007f8bdee833bb in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x00007f8bdee82e87 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#5  0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6  0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 5 (Thread 0x7f8bd82c3700 (LWP 3475) "kdevelo:disk$1"):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x55d9c2c7a138) at ../sysdeps/nptl/futex-internal.h:186
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55d9c2c7a0e8, cond=0x55d9c2c7a110) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x55d9c2c7a110, mutex=0x55d9c2c7a0e8) at pthread_cond_wait.c:638
#3  0x00007f8bdee833bb in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x00007f8bdee82e87 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#5  0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6  0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7f8be48e9700 (LWP 3474) "kdevelo:disk$0"):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x55d9c2c7a138) at ../sysdeps/nptl/futex-internal.h:186
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55d9c2c7a0e8, cond=0x55d9c2c7a110) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x55d9c2c7a110, mutex=0x55d9c2c7a0e8) at pthread_cond_wait.c:638
#3  0x00007f8bdee833bb in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x00007f8bdee82e87 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#5  0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6  0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7f8beca3e700 (LWP 3473) "QDBusConnection"):
#0  0x00007f8bf8da73ff in __GI___poll (fds=0x7f8be001a0b0, nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f8bf5aa50ae in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f8bf5aa51cf in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f8bf934d4bf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f8be0000b60, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#4  0x00007f8bf92f492b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7f8beca3db90, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#5  0x00007f8bf9113a3e in QThread::exec() (this=<optimized out>) at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#6  0x00007f8bf9d57a27 in  () at /lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x7f8bf9dc4d80) at thread/qthread_unix.cpp:329
#8  0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#9  0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7f8bed669700 (LWP 3472) "QXcbEventQueue"):
#0  0x00007f8bf8da73ff in __GI___poll (fds=0x7f8bed668ae8, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f8bf2243d02 in  () at /lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007f8bf224605a in xcb_wait_for_event () at /lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007f8bedb8a7e0 in  () at /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x00007f8bf9114b81 in QThreadPrivate::start(void*) (arg=0x55d9c28dc2f0) at thread/qthread_unix.cpp:329
#5  0x00007f8bf6439ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6  0x00007f8bf8db1def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f8bee71df00 (LWP 3471) "kdevelop"):
#0  KDevelop::Bucket<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, 0u>::deleteItem<KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u> >(unsigned short, unsigned int, KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u>&) (repository=<optimized out>, hash=<optimized out>, index=27172, this=0x7f8b78156cb0) at ./kdevplatform/serialization/itemrepository.h:546
#1  KDevelop::Bucket<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, 0u>::finalCleanup<KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u> >(KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u>&) (repository=<optimized out>, this=<optimized out>) at ./kdevplatform/serialization/itemrepository.h:696
#2  KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u>::finalCleanup() (this=<optimized out>) at ./kdevplatform/serialization/itemrepository.h:2199
#3  0x00007f8bf79883a3 in KDevelop::ItemRepositoryRegistry::finalCleanup() (this=<optimized out>) at ./kdevplatform/serialization/itemrepositoryregistry.cpp:387
#4  0x00007f8bf7d20ac9 in KDevelop::finalCleanup () at ./kdevplatform/language/duchain/duchain.cpp:1712
#5  KDevelop::DUChain::shutdown() (this=<optimized out>) at ./kdevplatform/language/duchain/duchain.cpp:1750
#6  0x00007f8bfab21958 in KDevelop::Core::cleanup() (this=0x55d9c2a16b30) at ./kdevplatform/shell/core.cpp:405
#7  0x00007f8bfab21b5c in KDevelop::Core::shutdown() (this=0x55d9c2a16b30) at ./kdevplatform/shell/core.cpp:360
#8  0x00007f8bfab0a3cb in KDevelop::MainWindow::~MainWindow() (this=0x55d9c2ab2ea0, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at ./kdevplatform/shell/mainwindow.cpp:150
#9  0x00007f8bfab0a429 in KDevelop::MainWindow::~MainWindow() (this=0x55d9c2ab2ea0, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at ./kdevplatform/shell/mainwindow.cpp:154
#10 0x00007f8bf9321d4f in QObject::event(QEvent*) (this=0x55d9c2ab2ea0, e=0x55d9c56a9ac0) at kernel/qobject.cpp:1301
#11 0x00007f8bf7506659 in KXmlGuiWindow::event(QEvent*) () at /lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#12 0x00007f8bf9f8a15f in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#13 0x00007f8bf92f5f6a in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x55d9c2ab2ea0, event=0x55d9c56a9ac0) at kernel/qcoreapplication.cpp:1063
#14 0x00007f8bf92f89a1 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (receiver=0x0, event_type=0, data=0x55d9c28caf00) at kernel/qcoreapplication.cpp:1817
#15 0x00007f8bf934de33 in postEventSourceDispatch(GSource*, GSourceFunc, gpointer) (s=0x55d9c29a9800) at kernel/qeventdispatcher_glib.cpp:277
#16 0x00007f8bf5aa4e6b in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007f8bf5aa5118 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007f8bf5aa51cf in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007f8bf934d4bf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x55d9c29a5d60, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#20 0x00007f8bf92f492b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7ffca145fc30, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#21 0x00007f8bf92fcba0 in QCoreApplication::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#22 0x000055d9c12d8e4d in main(int, char**) (argc=<optimized out>, argv=0x7ffca145fd98) at ./app/main.cpp:850

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.

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

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

I too am getting the hangs on exit. In the debugger I see it failing in KDevelop::Bucket<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, 0u>::deleteItem<KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u> > (repository=..., hash=<optimized out>, 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.

> 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.

I am still seeing this in the latest release.

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

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:

0x00007fbfc51630dd in KDevelop::Bucket<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, 0u>::followerIndex (index=0, this=<optimized out>) at /path/to/kdevelop/kdevplatform/serialization/itemrepository.h:1070
1070	        return *reinterpret_cast<unsigned short*>(m_data + (index - 2));
#0  0x00007fbfc51630dd in KDevelop::Bucket<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, 0u>::followerIndex (index=0, this=<optimized out>) at /path/to/kdevelop/kdevplatform/serialization/itemrepository.h:1070
#1  KDevelop::Bucket<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, 0u>::deleteItem<KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, QRecursiveMutex, 0u, 1048576u> > (repository=<optimized out>, hash=<optimized out>, index=44482, this=0x7fbf0cbc5ad0) at /path/to/kdevelop/kdevplatform/serialization/itemrepository.h:628
#2  KDevelop::Bucket<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, 0u>::finalCleanup<KDevelop::ItemRepository<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, QRecursiveMutex, 0u, 1048576u> > (repository=<optimized out>, this=<optimized out>) 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<Utils::SetNodeData, Utils::SetNodeDataRequest, false, 24u>, 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<KDevelop::AbstractTypeData, KDevelop::AbstractTypeDataRequest, true, 0u> 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.

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).