Discussion:
[Bug 379669] New: KDevelop continues to hang on exit in itemrepository.h
(too old to reply)
RJVB
2017-05-09 19:22:56 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

Bug ID: 379669
Summary: KDevelop continues to hang on exit in itemrepository.h
Product: kde
Version: unspecified
Platform: unspecified
OS: Linux
Status: UNCONFIRMED
Keywords: drkonqi
Severity: crash
Priority: NOR
Component: general
Assignee: unassigned-***@kde.org
Reporter: ***@gmail.com
Target Milestone: ---

Application: kdevelop5 (5.1.0)
(Compiled from sources)
Qt Version: 5.8.0
Frameworks Version: 5.32.0
Operating System: Linux 4.9.8-ck1-mainline-core2-rjvb x86_64
Distribution: Ubuntu 14.04.5 LTS

-- Information about the crash:
- What I was doing when the application crashed:

I don't recall what I had been doing in KDevelop, but when done I quit the
application. An hour later I realised my fan was still blowing, and I
discovered the KDevelop process burning 100% CPU.

The crash ensued when I terminated the process via KSysguard5.

This is a long-standing issue that somehow has become more frequent now that I
use libclang 4.0 for the C/C++ parser. The only still open ticket about it
concerns KDevelop 4.x and is thus no longer relevant (and besides DrKonqi won't
let me attach this information to that ticket). I'm opening a new ticket.

The only way I know to reproduce the issue is NOT to cross fingers that
KDevelop will really exit.

I wonder: does this finalCleanup() have any lasting side-effects like cleaning
up the on-disk cache, instead of just returning memory to the system that will
be returned anyway? If not, why not simply skip the step and let the runtime
return all memory to the system?

Alternatively, couldn't this be run earlier, before the global destruction
phase, for instance in reaction to QCoreApplication::aboutToQuit()?

The crash can be reproduced sometimes.

-- Backtrace:
Application: KDevelop (kdevelop5), signal: Floating point exception
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f7c7ae3e780 (LWP 13884))]

Thread 10 (Thread 0x7f7c59438700 (LWP 13887)):
#0 0x00007f7c77ba384d in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f7c67be4b72 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2 0x00007f7c67be664f in xcb_wait_for_event () from
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007f7c5c0c4549 in QXcbEventReader::run (this=0xdd26b0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/plugins/platforms/xcb/qxcbconnection.cpp:1345
#4 0x00007f7c78253cf9 in QThreadPrivate::start (arg=0xdd26b0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368
#5 0x00007f7c7178b184 in start_thread (arg=0x7f7c59438700) at
pthread_create.c:312
#6 0x00007f7c77bb0bed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 9 (Thread 0x7f7c53de3700 (LWP 13888)):
#0 0x00007f7c77ba1f3d in read () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f7c6f6caf80 in read (__nbytes=16, __buf=0x7f7c53de2c50,
__fd=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44
#2 g_wakeup_acknowledge (wakeup=0x7f7c540015b0) at gwakeup.c:210
#3 0x00007f7c6f679d7f in g_main_context_check
(context=***@entry=0x7f7c4c000990, max_priority=2147483647,
fds=***@entry=0x7f7c4c0100e0, n_fds=***@entry=1) at gmain.c:3695
#4 0x00007f7c6f67a28c in g_main_context_iterate
(context=***@entry=0x7f7c4c000990, block=***@entry=1,
dispatch=***@entry=1, self=<optimized out>) at gmain.c:3914
#5 0x00007f7c6f67a3ec in g_main_context_iteration (context=0x7f7c4c000990,
may_block=***@entry=1) at gmain.c:3978
#6 0x00007f7c7847159b in QEventDispatcherGlib::processEvents
(this=0x7f7c4c0008c0, flags=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:425
#7 0x00007f7c7841d17a in QEventLoop::exec (this=***@entry=0x7f7c53de2e20,
flags=..., ***@entry=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventloop.cpp:212
#8 0x00007f7c7824f2ab in QThread::exec (this=***@entry=0x7f7c7a256460
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread.cpp:507
#9 0x00007f7c79fe6005 in QDBusConnectionManager::run (this=0x7f7c7a256460
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusconnection.cpp:170
#10 0x00007f7c78253cf9 in QThreadPrivate::start (arg=0x7f7c7a256460 <(anonymous
namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368
#11 0x00007f7c7178b184 in start_thread (arg=0x7f7c53de3700) at
pthread_create.c:312
#12 0x00007f7c77bb0bed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 8 (Thread 0x7f7c46888700 (LWP 13890)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007f7c7824b485 in _q_futex (timeout=0x0, val=3, op=0, addr=0x18d4458)
at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qmutex_linux.cpp:123
#2 lockInternal_helper<false> (timeout=-1, elapsedTimer=0x0, d_ptr=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qmutex_linux.cpp:164
#3 QBasicMutex::lockInternal (this=0x18d4458) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qmutex_linux.cpp:180
#4 0x00007f7c7824b52a in lock (this=0x18d4458) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qmutex.h:73
#5 lock (timeout=-1, this=0x18d4440) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qmutex.cpp:695
#6 QMutex::lock (this=***@entry=0x7f7c764b3e88 <KDevelop::(anonymous
namespace)::Q_QGS_sdDUChainPrivate::innerFunction()::holder+8>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qmutex.cpp:227
#7 0x00007f7c75cdbe2b in QMutexLocker (m=<optimized out>, this=<synthetic
pointer>) at /opt/local/include/qt5/QtCore/qmutex.h:199
#8 KDevelop::DUChainPrivate::doMoreCleanup (this=0x7f7c764b3e80
<KDevelop::(anonymous
namespace)::Q_QGS_sdDUChainPrivate::innerFunction()::holder>,
retries=***@entry=1,
lockFlag=***@entry=KDevelop::DUChainPrivate::TryLock) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/language/duchain/duchain.cpp:703
#9 0x00007f7c75cdd021 in KDevelop::DUChainPrivate::CleanupThread::run
(this=0x18da400) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/language/duchain/duchain.cpp:290
#10 0x00007f7c78253cf9 in QThreadPrivate::start (arg=0x18da400) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368
#11 0x00007f7c7178b184 in start_thread (arg=0x7f7c46888700) at
pthread_create.c:312
#12 0x00007f7c77bb0bed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 7 (Thread 0x7f7c17fff700 (LWP 14352)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f7c78254aeb in wait (time=18446744073709551615, this=0x174cd90) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:143
#2 QWaitCondition::wait (this=<optimized out>, mutex=0x17d4700,
time=***@entry=18446744073709551615) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:215
#3 0x00007f7c6cc91e7b in
ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned_locked
(this=***@entry=0x1744e10, th=***@entry=0x2b58ab0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/weaver.cpp:594
#4 0x00007f7c6cc91ebb in
ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned (this=0x1744e10,
th=0x2b58ab0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/weaver.cpp:581
#5 0x00007f7c6cc97201 in ThreadWeaver::SuspendingState::applyForWork
(this=0x17cd5c0, th=0x2b58ab0, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/suspendingstate.cpp:61
#6 0x00007f7c6cc91dbf in ThreadWeaver::Weaver::applyForWork (this=<optimized
out>, th=0x2b58ab0, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/weaver.cpp:568
#7 0x00007f7c6cc97012 in ThreadWeaver::WorkingHardState::applyForWork
(this=0x17d44b0, th=0x2b58ab0, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/workinghardstate.cpp:73
#8 0x00007f7c6cc91dbf in ThreadWeaver::Weaver::applyForWork (this=<optimized
out>, th=0x2b58ab0, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/weaver.cpp:568
#9 0x00007f7c6cc97012 in ThreadWeaver::WorkingHardState::applyForWork
(this=0x17d44b0, th=0x2b58ab0, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/workinghardstate.cpp:73
#10 0x00007f7c6cc91dbf in ThreadWeaver::Weaver::applyForWork (this=<optimized
out>, th=0x2b58ab0, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/weaver.cpp:568
#11 0x00007f7c6cc949c9 in ThreadWeaver::Thread::run (this=0x2b58ab0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/thread.cpp:103
#12 0x00007f7c78253cf9 in QThreadPrivate::start (arg=0x2b58ab0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368
#13 0x00007f7c7178b184 in start_thread (arg=0x7f7c17fff700) at
pthread_create.c:312
#14 0x00007f7c77bb0bed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 6 (Thread 0x7f7c2f7fe700 (LWP 14353)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f7c78254aeb in wait (time=18446744073709551615, this=0x174cd90) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:143
#2 QWaitCondition::wait (this=<optimized out>, mutex=0x17d4700,
time=***@entry=18446744073709551615) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:215
#3 0x00007f7c6cc91e7b in
ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned_locked
(this=***@entry=0x1744e10, th=***@entry=0x7f7c1c0e9b30) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/weaver.cpp:594
#4 0x00007f7c6cc91ebb in
ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned (this=0x1744e10,
th=0x7f7c1c0e9b30) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/weaver.cpp:581
#5 0x00007f7c6cc97201 in ThreadWeaver::SuspendingState::applyForWork
(this=0x17cd5c0, th=0x7f7c1c0e9b30, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/suspendingstate.cpp:61
#6 0x00007f7c6cc91dbf in ThreadWeaver::Weaver::applyForWork (this=<optimized
out>, th=0x7f7c1c0e9b30, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/weaver.cpp:568
#7 0x00007f7c6cc949c9 in ThreadWeaver::Thread::run (this=0x7f7c1c0e9b30) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/thread.cpp:103
#8 0x00007f7c78253cf9 in QThreadPrivate::start (arg=0x7f7c1c0e9b30) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368
#9 0x00007f7c7178b184 in start_thread (arg=0x7f7c2f7fe700) at
pthread_create.c:312
#10 0x00007f7c77bb0bed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 5 (Thread 0x7f7c2cd5b700 (LWP 14354)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f7c78254aeb in wait (time=18446744073709551615, this=0x174cd90) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:143
#2 QWaitCondition::wait (this=<optimized out>, mutex=0x17d4700,
time=***@entry=18446744073709551615) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:215
#3 0x00007f7c6cc91e7b in
ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned_locked
(this=***@entry=0x1744e10, th=***@entry=0x7f7c180ba740) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/weaver.cpp:594
#4 0x00007f7c6cc91ebb in
ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned (this=0x1744e10,
th=0x7f7c180ba740) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/weaver.cpp:581
#5 0x00007f7c6cc97201 in ThreadWeaver::SuspendingState::applyForWork
(this=0x17cd5c0, th=0x7f7c180ba740, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/suspendingstate.cpp:61
#6 0x00007f7c6cc91dbf in ThreadWeaver::Weaver::applyForWork (this=<optimized
out>, th=0x7f7c180ba740, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/weaver.cpp:568
#7 0x00007f7c6cc97012 in ThreadWeaver::WorkingHardState::applyForWork
(this=0x17d44b0, th=0x7f7c180ba740, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/workinghardstate.cpp:73
#8 0x00007f7c6cc91dbf in ThreadWeaver::Weaver::applyForWork (this=<optimized
out>, th=0x7f7c180ba740, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/weaver.cpp:568
#9 0x00007f7c6cc97012 in ThreadWeaver::WorkingHardState::applyForWork
(this=0x17d44b0, th=0x7f7c180ba740, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/workinghardstate.cpp:73
#10 0x00007f7c6cc91dbf in ThreadWeaver::Weaver::applyForWork (this=<optimized
out>, th=0x7f7c180ba740, wasBusy=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/weaver.cpp:568
#11 0x00007f7c6cc949c9 in ThreadWeaver::Thread::run (this=0x7f7c180ba740) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.32.0/src/thread.cpp:103
#12 0x00007f7c78253cf9 in QThreadPrivate::start (arg=0x7f7c180ba740) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368
#13 0x00007f7c7178b184 in start_thread (arg=0x7f7c2cd5b700) at
pthread_create.c:312
#14 0x00007f7c77bb0bed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 4 (Thread 0x7f7c2e92e700 (LWP 14365)):
#0 0x00007f7c77ba1f3d in read () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f7c6f6caf80 in read (__nbytes=16, __buf=0x7f7c2e92dc80,
__fd=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44
#2 g_wakeup_acknowledge (wakeup=0x7f7c20166200) at gwakeup.c:210
#3 0x00007f7c6f679d7f in g_main_context_check
(context=***@entry=0x7f7c20437cd0, max_priority=2147483647,
fds=***@entry=0x7f7c202a0d10, n_fds=***@entry=1) at gmain.c:3695
#4 0x00007f7c6f67a28c in g_main_context_iterate
(context=***@entry=0x7f7c20437cd0, block=***@entry=1,
dispatch=***@entry=1, self=<optimized out>) at gmain.c:3914
#5 0x00007f7c6f67a3ec in g_main_context_iteration (context=0x7f7c20437cd0,
may_block=***@entry=1) at gmain.c:3978
#6 0x00007f7c7847159b in QEventDispatcherGlib::processEvents
(this=0x7f7c202ed5f0, flags=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:425
#7 0x00007f7c7841d17a in QEventLoop::exec (this=***@entry=0x7f7c2e92de50,
flags=..., ***@entry=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventloop.cpp:212
#8 0x00007f7c7824f2ab in QThread::exec (this=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread.cpp:507
#9 0x00007f7c78253cf9 in QThreadPrivate::start (arg=0x7f7c69c06808
<KDevelop::(anonymous
namespace)::Q_QGS_s_parsingThread::innerFunction()::holder+8>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368
#10 0x00007f7c7178b184 in start_thread (arg=0x7f7c2e92e700) at
pthread_create.c:312
#11 0x00007f7c77bb0bed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7f7c177fe700 (LWP 14484)):
#0 0x00007f7c77ba384d in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f7c6f67a2e6 in g_main_context_poll (priority=<optimized out>,
n_fds=1, fds=0x7f7c1016d200, timeout=<optimized out>, context=0x7f7c1004dab0)
at gmain.c:4216
#2 g_main_context_iterate (context=***@entry=0x7f7c1004dab0,
block=***@entry=1, dispatch=***@entry=1, self=<optimized out>) at
gmain.c:3912
#3 0x00007f7c6f67a3ec in g_main_context_iteration (context=0x7f7c1004dab0,
may_block=***@entry=1) at gmain.c:3978
#4 0x00007f7c7847159b in QEventDispatcherGlib::processEvents
(this=0x7f7c100d50f0, flags=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:425
#5 0x00007f7c7841d17a in QEventLoop::exec (this=***@entry=0x7f7c177fde30,
flags=..., ***@entry=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventloop.cpp:212
#6 0x00007f7c7824f2ab in QThread::exec (this=***@entry=0x78d15e0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread.cpp:507
#7 0x00007f7c6d8cca25 in QQmlThreadPrivate::run (this=0x78d15e0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtdeclarative/src/qml/qml/ftw/qqmlthread.cpp:147
#8 0x00007f7c78253cf9 in QThreadPrivate::start (arg=0x78d15e0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368
#9 0x00007f7c7178b184 in start_thread (arg=0x7f7c177fe700) at
pthread_create.c:312
#10 0x00007f7c77bb0bed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7f7beeffd700 (LWP 14826)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f7c696d53a4 in QTWTF::TCMalloc_PageHeap::scavengerThread
(this=0x7f7c699be220 <QTWTF::pageheap_memory>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtscript/src/3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:2359
#2 0x00007f7c696d53e9 in QTWTF::TCMalloc_PageHeap::runScavengerThread
(context=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtscript/src/3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:1464
#3 0x00007f7c7178b184 in start_thread (arg=0x7f7beeffd700) at
pthread_create.c:312
#4 0x00007f7c77bb0bed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7f7c7ae3e780 (LWP 13884)):
[KCrash Handler]
#6 deleteItem<KDevelop::ItemRepository<KDevelop::AbstractTypeData,
KDevelop::AbstractTypeDataRequest> > (repository=..., hash=<optimized out>,
index=59284, this=0x7f7c1c1b99b0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/serialization/itemrepository.h:545
#7 finalCleanup<KDevelop::ItemRepository<KDevelop::AbstractTypeData,
KDevelop::AbstractTypeDataRequest> > (repository=..., this=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/serialization/itemrepository.h:677
#8 KDevelop::ItemRepository<KDevelop::AbstractTypeData,
KDevelop::AbstractTypeDataRequest, true, true, 0u, 1048576u>::finalCleanup
(this=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/serialization/itemrepository.h:2074
#9 0x00007f7c74e50b39 in KDevelop::ItemRepositoryRegistry::finalCleanup
(this=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/serialization/itemrepositoryregistry.cpp:366
#10 0x00007f7c75cc86a5 in finalCleanup () at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/language/duchain/duchain.cpp:1585
#11 KDevelop::DUChain::shutdown (this=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/language/duchain/duchain.cpp:1623
#12 0x00007f7c7a9a3503 in KDevelop::Core::cleanup (this=***@entry=0x14e3e90)
at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/shell/core.cpp:461
#13 0x00007f7c7a9a3778 in KDevelop::Core::shutdown (this=0x14e3e90) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/shell/core.cpp:412
#14 0x00007f7c7a98262b in KDevelop::MainWindow::~MainWindow
(this=***@entry=0x1348300, __in_chrg=<optimized out>, __vtt_parm=<optimized
out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/shell/mainwindow.cpp:158
#15 0x00007f7c7a982679 in KDevelop::MainWindow::~MainWindow (this=0x1348300,
__in_chrg=<optimized out>, __vtt_parm=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/shell/mainwindow.cpp:162
#16 0x00007f7c7844b158 in QObject::event (this=***@entry=0x1348300,
e=***@entry=0x84c6b80) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qobject.cpp:1254
#17 0x00007f7c791d82a3 in QWidget::event (this=***@entry=0x1348300,
event=***@entry=0x84c6b80) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/widgets/kernel/qwidget.cpp:9220
#18 0x00007f7c792ce6db in QMainWindow::event (this=***@entry=0x1348300,
event=***@entry=0x84c6b80) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/widgets/widgets/qmainwindow.cpp:1557
#19 0x00007f7c7440ef0a in KMainWindow::event (this=***@entry=0x1348300,
ev=***@entry=0x84c6b80) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-kxmlgui/work/kxmlgui-5.32.0/src/kmainwindow.cpp:867
#20 0x00007f7c7445e5d5 in KXmlGuiWindow::event (this=0x1348300, ev=0x84c6b80)
at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-kxmlgui/work/kxmlgui-5.32.0/src/kxmlguiwindow.cpp:119
#21 0x00007f7c791938ac in QApplicationPrivate::notify_helper (this=<optimized
out>, receiver=0x1348300, e=0x84c6b80) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/widgets/kernel/qapplication.cpp:3745
#22 0x00007f7c7919ab21 in QApplication::notify (this=0x7ffef719b4a0,
receiver=0x1348300, e=0x84c6b80) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/widgets/kernel/qapplication.cpp:3502
#23 0x00007f7c7841f018 in QCoreApplication::notifyInternal2
(receiver=0x1348300, event=***@entry=0x84c6b80) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qcoreapplication.cpp:995
#24 0x00007f7c7842167d in sendEvent (event=0x84c6b80, receiver=<optimized out>)
at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qcoreapplication.h:231
#25 QCoreApplicationPrivate::sendPostedEvents (receiver=***@entry=0x0,
event_type=***@entry=0, data=0xdac550) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qcoreapplication.cpp:1655
#26 0x00007f7c78421ae8 in QCoreApplication::sendPostedEvents
(receiver=***@entry=0x0, event_type=***@entry=0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qcoreapplication.cpp:1509
#27 0x00007f7c78471173 in postEventSourceDispatch (s=0xdf40e0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:276
#28 0x00007f7c6f67a0f7 in g_main_dispatch (context=0x7f7c540016f0) at
gmain.c:3191
#29 g_main_context_dispatch (context=***@entry=0x7f7c540016f0) at
gmain.c:3844
#30 0x00007f7c6f67a348 in g_main_context_iterate
(context=***@entry=0x7f7c540016f0, block=***@entry=1,
dispatch=***@entry=1, self=<optimized out>) at gmain.c:3917
#31 0x00007f7c6f67a3ec in g_main_context_iteration (context=0x7f7c540016f0,
may_block=***@entry=1) at gmain.c:3978
#32 0x00007f7c7847157f in QEventDispatcherGlib::processEvents (this=0xdf8160,
flags=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:423
#33 0x00007f7c7841d17a in QEventLoop::exec (this=***@entry=0x7ffef719b260,
flags=..., ***@entry=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventloop.cpp:212
#34 0x00007f7c78425524 in QCoreApplication::exec () at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qcoreapplication.cpp:1268
#35 0x00007f7c78989b8c in QGuiApplication::exec () at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/gui/kernel/qguiapplication.cpp:1661
#36 0x00007f7c79193805 in QApplication::exec () at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/widgets/kernel/qapplication.cpp:2921
#37 0x000000000040b8d2 in main (argc=<optimized out>, argv=<optimized out>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevelop5/kf5-kdevelop-devel/work/kf5-kdevelop-5/app/main.cpp:895

Possible duplicates by query: bug 369238, bug 369237.

Reported using DrKonqi
--
You are receiving this mail because:
You are watching all bug changes.
RJVB
2017-05-09 19:32:04 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

RJVB <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.kde.org/show_b
| |ug.cgi?id=363861
--
You are receiving this mail because:
You are watching all bug changes.
RJVB
2017-05-09 19:34:19 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #1 from RJVB <***@gmail.com> ---
*** Bug 363861 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are watching all bug changes.
RJVB
2017-05-09 20:05:01 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #2 from RJVB <***@gmail.com> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
Christoph Feck
2017-05-09 23:43:06 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

Christoph Feck <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Product|kde |kdevelop
Component|general |general
Assignee|unassigned-***@kde.org |kdevelop-bugs-***@kde.org
--
You are receiving this mail because:
You are watching all bug changes.
Kevin Funk
2017-05-10 07:32:08 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

Kevin Funk <***@kde.org> 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.
Kevin Funk
2017-05-10 07:37:00 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

Kevin Funk <***@kde.org> 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.
RJVB
2017-05-10 09:30:28 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #3 from RJVB <***@gmail.com> ---
Created attachment 105430
--> https://bugs.kde.org/attachment.cgi?id=105430&action=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.
RJVB
2017-05-10 15:12:51 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

RJVB <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #105430|0 |1
is obsolete| |

--- Comment #4 from RJVB <***@gmail.com> ---
Created attachment 105432
--> https://bugs.kde.org/attachment.cgi?id=105432&action=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.
RJVB
2017-05-16 12:25:02 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

RJVB <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #105432|0 |1
is obsolete| |

--- Comment #5 from RJVB <***@gmail.com> ---
Created attachment 105591
--> https://bugs.kde.org/attachment.cgi?id=105591&action=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.
RJVB
2017-05-19 08:14:32 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #6 from RJVB <***@gmail.com> ---
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.
Francis Herne
2017-05-22 13:22:57 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

Francis Herne <***@flherne.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@flherne.uk

--- Comment #7 from Francis Herne <***@flherne.uk> ---
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.
RJVB
2017-05-22 14:34:04 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #8 from RJVB <***@gmail.com> ---
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.
RJVB
2017-07-07 13:59:06 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

RJVB <***@gmail.com> 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.
Kevin Funk
2017-08-04 08:47:03 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #9 from Kevin Funk <***@kde.org> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
RJVB
2017-08-04 09:11:19 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #10 from RJVB <***@gmail.com> ---
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.
Kevin Funk
2017-08-07 07:50:11 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #11 from Kevin Funk <***@kde.org> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
Francis Herne
2017-09-01 21:29:01 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #12 from Francis Herne <***@flherne.uk> ---
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.
Kevin Funk
2017-09-07 09:23:30 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

Kevin Funk <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@art-master
| |.de, ***@milianw.de

--- Comment #13 from Kevin Funk <***@kde.org> ---
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.
RJVB
2017-09-19 12:51:48 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #14 from RJVB <***@gmail.com> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
RJVB
2018-06-28 14:23:39 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #15 from RJVB <***@gmail.com> ---
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.
RJVB
2018-06-28 14:27:12 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

RJVB <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #105591|0 |1
is obsolete| |

--- Comment #16 from RJVB <***@gmail.com> ---
Created attachment 113627
--> https://bugs.kde.org/attachment.cgi?id=113627&action=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.
Raúl
2018-07-30 08:38:43 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

Raúl <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com
--
You are receiving this mail because:
You are watching all bug changes.
David Nolden
2018-08-09 12:53:34 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #17 from David Nolden <***@art-master.de> ---
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.
David Nolden
2018-08-09 12:59:55 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #18 from David Nolden <***@art-master.de> ---
Btw. the cleanup is mainly concerning the on-disk cache structure.
--
You are receiving this mail because:
You are watching all bug changes.
RJVB
2018-08-09 13:23:25 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #19 from RJVB <***@gmail.com> ---
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.
David Nolden
2018-08-09 14:32:43 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #20 from David Nolden <***@art-master.de> ---
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.
David Nolden
2018-08-09 14:39:47 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #21 from David Nolden <***@art-master.de> ---
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.
David Nolden
2018-08-09 14:42:53 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #22 from David Nolden <***@art-master.de> ---
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.
RJVB
2018-08-09 16:09:03 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669
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.
David Nolden
2018-08-09 17:54:13 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #24 from David Nolden <***@art-master.de> ---
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.
RJVB
2018-08-09 19:45:08 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #25 from RJVB <***@gmail.com> ---
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
```
--
You are receiving this mail because:
You are watching all bug changes.
David Nolden
2018-08-10 16:00:28 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #26 from David Nolden <***@art-master.de> ---
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.
David Nolden
2018-08-13 12:31:40 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #27 from David Nolden <***@art-master.de> ---
Created attachment 114420
--> https://bugs.kde.org/attachment.cgi?id=114420&action=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.
RJVB
2018-08-13 15:16:40 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #28 from RJVB <***@gmail.com> ---
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.
RJVB
2018-08-13 16:27:12 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #29 from RJVB <***@gmail.com> ---
Created attachment 114422
--> https://bugs.kde.org/attachment.cgi?id=114422&action=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.
David Nolden
2018-08-21 14:47:17 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #30 from David Nolden <***@art-master.de> ---
Created attachment 114532
--> https://bugs.kde.org/attachment.cgi?id=114532&action=edit
Patch to debug loading/unloading of python plugin
--
You are receiving this mail because:
You are watching all bug changes.
David Nolden
2018-08-21 14:49:59 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=379669

--- Comment #31 from David Nolden <***@art-master.de> ---
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.
Loading...