Bug 194483 (build_addjob_crash)

Summary: Crash on build command for a project that was closed, and then reopened
Product: [Applications] kdevelop Reporter: Ramón Zarazúa <killerfox512>
Component: generalAssignee: kdevelop-bugs-null
Status: RESOLVED WORKSFORME    
Severity: crash CC: albzey, armin, christophe, craig.magina, crissi99, david.nolden.kde, davide.rondini, eduardosanchezmunoz, freebsd, gpiez, guido-kdebugs, janitor048, mail, marco.krohn, Maxim.Prohorenko, nicotra.andrea, olivier.jg, rbyshko, rob.frohne, schmittsebastian, sebastian-krieger, thorbenk, xxtjaxx, yuriy.kozlov
Priority: VHI Keywords: investigated, triaged
Version: unspecified   
Target Milestone: 4.0.0   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Backtrace
backtrace for crash when hitting F8 in order to compile project
backtrace for reproducible crash (see comment 11)
console output for reproducible crash (see comment 11)
More console output
Make it stop crashing
New crash information added by DrKonqi

Description Ramón Zarazúa 2009-05-28 23:31:05 UTC 
Version:            (using KDE 4.2.85)
Compiler:          gcc 4.2.3 
OS:                Linux
Installed from:    Compiled From Sources

Two projects were loaded, I unload, and reload both, and after they were done, a build command on a target(folder selected + F8) crashed.
Comment 1 Ramón Zarazúa 2009-05-28 23:32:08 UTC 
Created attachment 34086 [details]
Backtrace

This is the backtrace
Comment 2 Andreas Pakulat 2009-05-28 23:48:50 UTC 
I've seen this happen once, but cannot reproduce it. Also the backtrace doesn't make any sense as we already check all pointers that we're going to use in the if() part.

Ramon, can you reproduce this with the steps you provided? If so can you try running kdevelop through valgrind to see why it crashes there.
Comment 3 Dario Andres 2009-05-29 15:29:55 UTC 
Pasted backtrace from comment 1:
-----

Application: KDevelop (kdevelop), signal: Segmentation fault
[Current thread is 1 (Thread 0x7f7bd48b8750 (LWP 12424))]

Thread 11 (Thread 0x7f7bc24bd950 (LWP 12426)):
#0  0x00007f7bd11f5fdd in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f7bd1466eb7 in QWaitCondition::wait (this=0x1564ff8, mutex=0x1565000, time=200000) at thread/qwaitcondition_unix.cpp:85
#2  0x00007f7bce24a773 in KDevelop::DUChainPrivate::CleanupThread::run (this=0x1564fe0) at /home/kde-devel/kde/sources/trunk/KDE/kdevplatform/language/duchain/duchain.cpp:280
#3  0x00007f7bd1465f22 in QThreadPrivate::start (arg=0x1564fe0) at thread/qthread_unix.cpp:189
#4  0x00007f7bd11f2070 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f7bcf9b210d in clone () from /lib64/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 10 (Thread 0x7f7bb5243950 (LWP 12618)):
#0  0x00007f7bcf9a9386 in poll () from /lib64/libc.so.6
#1  0x00007f7bc9ebf768 in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f7bc9ebfa8b in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f7bd15788be in QEventDispatcherGlib::processEvents (this=0x3014280, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:326
#4  0x00007f7bd154d9f2 in QEventLoop::processEvents (this=<value optimized out>, flags={i = -1255919600}) at kernel/qeventloop.cpp:149
#5  0x00007f7bd154ddbd in QEventLoop::exec (this=0x7f7bb5243050, flags={i = -1255919520}) at kernel/qeventloop.cpp:200
#6  0x00007f7bd1462f88 in QThread::exec (this=<value optimized out>) at thread/qthread.cpp:487
#7  0x00007f7bce344a7b in KDevelop::CompletionWorkerThread::run (this=0x3013830) at /home/kde-devel/kde/sources/trunk/KDE/kdevplatform/language/codecompletion/codecompletionmodel.cpp:79
#8  0x00007f7bd1465f22 in QThreadPrivate::start (arg=0x3013830) at thread/qthread_unix.cpp:189
#9  0x00007f7bd11f2070 in start_thread () from /lib64/libpthread.so.0
#10 0x00007f7bcf9b210d in clone () from /lib64/libc.so.6
#11 0x0000000000000000 in ?? ()

Thread 9 (Thread 0x7f7bb4a42950 (LWP 12619)):
#0  0x00007f7bd11f4d80 in __pthread_mutex_unlock_usercnt () from /lib64/libpthread.so.0
#1  0x00007f7bc9ebf7c9 in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f7bc9ebfa8b in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f7bd15788be in QEventDispatcherGlib::processEvents (this=0x2ff1820, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:326
#4  0x00007f7bd154d9f2 in QEventLoop::processEvents (this=<value optimized out>, flags={i = -1264312304}) at kernel/qeventloop.cpp:149
#5  0x00007f7bd154ddbd in QEventLoop::exec (this=0x7f7bb4a42050, flags={i = -1264312224}) at kernel/qeventloop.cpp:200
#6  0x00007f7bd1462f88 in QThread::exec (this=<value optimized out>) at thread/qthread.cpp:487
#7  0x00007f7bce344a7b in KDevelop::CompletionWorkerThread::run (this=0x2ff9970) at /home/kde-devel/kde/sources/trunk/KDE/kdevplatform/language/codecompletion/codecompletionmodel.cpp:79
#8  0x00007f7bd1465f22 in QThreadPrivate::start (arg=0x2ff9970) at thread/qthread_unix.cpp:189
#9  0x00007f7bd11f2070 in start_thread () from /lib64/libpthread.so.0
#10 0x00007f7bcf9b210d in clone () from /lib64/libc.so.6
#11 0x0000000000000000 in ?? ()

Thread 8 (Thread 0x7f7bb5a44950 (LWP 12624)):
#0  0x00007f7bd11f5fdd in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f7bd1465965 in thread_sleep (ti=0x7f7bb5a44030) at thread/qthread_unix.cpp:298
#2  0x00007f7bd1465ace in QThread::msleep (msecs=30) at thread/qthread_unix.cpp:324
#3  0x00007f7bac5d0102 in UIBlockTester::UIBlockTesterThread::run (this=0x394dbb0) at /home/kde-devel/kde/sources/trunk/KDE/kdevelop/languages/cpp/cpplanguagesupport.cpp:965
#4  0x00007f7bd1465f22 in QThreadPrivate::start (arg=0x394dbb0) at thread/qthread_unix.cpp:189
#5  0x00007f7bd11f2070 in start_thread () from /lib64/libpthread.so.0
#6  0x00007f7bcf9b210d in clone () from /lib64/libc.so.6
#7  0x0000000000000000 in ?? ()

Thread 7 (Thread 0x7f7baaa34950 (LWP 17551)):
#0  0x00007f7bd11f5d59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f7bd1466ed9 in QWaitCondition::wait (this=0x170d4b8, mutex=0x16eec70, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:87
#2  0x00007f7bd2d0be11 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0x170d490, th=0x5819680)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:365
#3  0x00007f7bd2d10557 in ThreadWeaver::WorkingHardState::waitForAvailableJob (this=0x16eed50, th=0x5819680)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:80
#4  0x00007f7bd2d0b586 in ThreadWeaver::WeaverImpl::waitForAvailableJob (this=0x170d490, th=0x5819680) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:356
#5  0x00007f7bd2d1064f in ThreadWeaver::WorkingHardState::applyForWork (this=0x16eed50, th=0x5819680) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:71
#6  0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x170d490, th=0x5819680, previous=0x0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#7  0x00007f7bd2d10672 in ThreadWeaver::WorkingHardState::applyForWork (this=0x16eed50, th=0x5819680) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:74
#8  0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x170d490, th=0x5819680, previous=0x5becd10)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#9  0x00007f7bd2d0e8ec in ThreadWeaver::ThreadRunHelper::run (this=0x7f7baaa34080, parent=0x170d490, th=0x5819680) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/Thread.cpp:87
#10 0x00007f7bd2d0ea81 in ThreadWeaver::Thread::run (this=0x5819680) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/Thread.cpp:142
#11 0x00007f7bd1465f22 in QThreadPrivate::start (arg=0x5819680) at thread/qthread_unix.cpp:189
#12 0x00007f7bd11f2070 in start_thread () from /lib64/libpthread.so.0
#13 0x00007f7bcf9b210d in clone () from /lib64/libc.so.6
#14 0x0000000000000000 in ?? ()

Thread 6 (Thread 0x7f7baa233950 (LWP 17552)):
#0  0x00007f7bd11f5d59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f7bd1466ed9 in QWaitCondition::wait (this=0x170d4b8, mutex=0x16eec70, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:87
#2  0x00007f7bd2d0be11 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0x170d490, th=0x5e77d10)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:365
#3  0x00007f7bd2d10557 in ThreadWeaver::WorkingHardState::waitForAvailableJob (this=0x16eed50, th=0x5e77d10)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:80
#4  0x00007f7bd2d0b586 in ThreadWeaver::WeaverImpl::waitForAvailableJob (this=0x170d490, th=0x5e77d10) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:356
#5  0x00007f7bd2d1064f in ThreadWeaver::WorkingHardState::applyForWork (this=0x16eed50, th=0x5e77d10) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:71
#6  0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x170d490, th=0x5e77d10, previous=0x7951740)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#7  0x00007f7bd2d0e8ec in ThreadWeaver::ThreadRunHelper::run (this=0x7f7baa233080, parent=0x170d490, th=0x5e77d10) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/Thread.cpp:87
#8  0x00007f7bd2d0ea81 in ThreadWeaver::Thread::run (this=0x5e77d10) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/Thread.cpp:142
#9  0x00007f7bd1465f22 in QThreadPrivate::start (arg=0x5e77d10) at thread/qthread_unix.cpp:189
#10 0x00007f7bd11f2070 in start_thread () from /lib64/libpthread.so.0
#11 0x00007f7bcf9b210d in clone () from /lib64/libc.so.6
#12 0x0000000000000000 in ?? ()

Thread 5 (Thread 0x7f7ba9714950 (LWP 17579)):
#0  0x00007f7bd11f5d59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f7bd1466ed9 in QWaitCondition::wait (this=0x667caf8, mutex=0x667ce60, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:87
#2  0x00007f7bd2d0be11 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0x667cad0, th=0x667d440)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:365
#3  0x00007f7bd2d10557 in ThreadWeaver::WorkingHardState::waitForAvailableJob (this=0x667cf40, th=0x667d440)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:80
#4  0x00007f7bd2d0b586 in ThreadWeaver::WeaverImpl::waitForAvailableJob (this=0x667cad0, th=0x667d440) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:356
#5  0x00007f7bd2d1064f in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x667d440) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:71
#6  0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x667d440, previous=0x5a13b20)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#7  0x00007f7bd2d0e8ec in ThreadWeaver::ThreadRunHelper::run (this=0x7f7ba9714080, parent=0x667cad0, th=0x667d440) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/Thread.cpp:87
#8  0x00007f7bd2d0ea81 in ThreadWeaver::Thread::run (this=0x667d440) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/Thread.cpp:142
#9  0x00007f7bd1465f22 in QThreadPrivate::start (arg=0x667d440) at thread/qthread_unix.cpp:189
#10 0x00007f7bd11f2070 in start_thread () from /lib64/libpthread.so.0
#11 0x00007f7bcf9b210d in clone () from /lib64/libc.so.6
#12 0x0000000000000000 in ?? ()

Thread 4 (Thread 0x7f7ba8f13950 (LWP 17580)):
#0  0x00007f7bd11f5d59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f7bd1466ed9 in QWaitCondition::wait (this=0x667caf8, mutex=0x667ce60, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:87
#2  0x00007f7bd2d0be11 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0x667cad0, th=0x67614f0)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:365
#3  0x00007f7bd2d10557 in ThreadWeaver::WorkingHardState::waitForAvailableJob (this=0x667cf40, th=0x67614f0)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:80
#4  0x00007f7bd2d0b586 in ThreadWeaver::WeaverImpl::waitForAvailableJob (this=0x667cad0, th=0x67614f0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:356
#5  0x00007f7bd2d1064f in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x67614f0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:71
#6  0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x67614f0, previous=0x0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#7  0x00007f7bd2d10672 in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x67614f0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:74
#8  0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x67614f0, previous=0x0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#9  0x00007f7bd2d10672 in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x67614f0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:74
#10 0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x67614f0, previous=0x0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#11 0x00007f7bd2d10672 in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x67614f0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:74
#12 0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x67614f0, previous=0x7921fa0)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#13 0x00007f7bd2d0e8ec in ThreadWeaver::ThreadRunHelper::run (this=0x7f7ba8f13080, parent=0x667cad0, th=0x67614f0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/Thread.cpp:87
#14 0x00007f7bd2d0ea81 in ThreadWeaver::Thread::run (this=0x67614f0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/Thread.cpp:142
#15 0x00007f7bd1465f22 in QThreadPrivate::start (arg=0x67614f0) at thread/qthread_unix.cpp:189
#16 0x00007f7bd11f2070 in start_thread () from /lib64/libpthread.so.0
#17 0x00007f7bcf9b210d in clone () from /lib64/libc.so.6
#18 0x0000000000000000 in ?? ()

Thread 3 (Thread 0x7f7ba8712950 (LWP 17581)):
#0  0x00007f7bd11f5d59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f7bd1466ed9 in QWaitCondition::wait (this=0x667caf8, mutex=0x667ce60, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:87
#2  0x00007f7bd2d0be11 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0x667cad0, th=0x67952f0)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:365
#3  0x00007f7bd2d10557 in ThreadWeaver::WorkingHardState::waitForAvailableJob (this=0x667cf40, th=0x67952f0)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:80
#4  0x00007f7bd2d0b586 in ThreadWeaver::WeaverImpl::waitForAvailableJob (this=0x667cad0, th=0x67952f0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:356
#5  0x00007f7bd2d1064f in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x67952f0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:71
#6  0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x67952f0, previous=0x0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#7  0x00007f7bd2d10672 in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x67952f0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:74
#8  0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x67952f0, previous=0x88bfad0)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#9  0x00007f7bd2d0e8ec in ThreadWeaver::ThreadRunHelper::run (this=0x7f7ba8712080, parent=0x667cad0, th=0x67952f0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/Thread.cpp:87
#10 0x00007f7bd2d0ea81 in ThreadWeaver::Thread::run (this=0x67952f0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/Thread.cpp:142
#11 0x00007f7bd1465f22 in QThreadPrivate::start (arg=0x67952f0) at thread/qthread_unix.cpp:189
#12 0x00007f7bd11f2070 in start_thread () from /lib64/libpthread.so.0
#13 0x00007f7bcf9b210d in clone () from /lib64/libc.so.6
#14 0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7f7ba7dee950 (LWP 17667)):
#0  0x00007f7bd11f5d59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f7bd1466ed9 in QWaitCondition::wait (this=0x667caf8, mutex=0x667ce60, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:87
#2  0x00007f7bd2d0be11 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0x667cad0, th=0x66fbee0)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:365
#3  0x00007f7bd2d10557 in ThreadWeaver::WorkingHardState::waitForAvailableJob (this=0x667cf40, th=0x66fbee0)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:80
#4  0x00007f7bd2d0b586 in ThreadWeaver::WeaverImpl::waitForAvailableJob (this=0x667cad0, th=0x66fbee0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:356
#5  0x00007f7bd2d1064f in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x66fbee0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:71
#6  0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x66fbee0, previous=0x0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#7  0x00007f7bd2d10672 in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x66fbee0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:74
#8  0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x66fbee0, previous=0x0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#9  0x00007f7bd2d10672 in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x66fbee0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:74
#10 0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x66fbee0, previous=0x0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#11 0x00007f7bd2d10672 in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x66fbee0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:74
#12 0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x66fbee0, previous=0x0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#13 0x00007f7bd2d10672 in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x66fbee0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:74
#14 0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x66fbee0, previous=0x0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#15 0x00007f7bd2d10672 in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x66fbee0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:74
#16 0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x66fbee0, previous=0x0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#17 0x00007f7bd2d10672 in ThreadWeaver::WorkingHardState::applyForWork (this=0x667cf40, th=0x66fbee0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:74
#18 0x00007f7bd2d0c04d in ThreadWeaver::WeaverImpl::applyForWork (this=0x667cad0, th=0x66fbee0, previous=0x73ef4c0)
    at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
#19 0x00007f7bd2d0e8ec in ThreadWeaver::ThreadRunHelper::run (this=0x7f7ba7dee080, parent=0x667cad0, th=0x66fbee0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/Thread.cpp:87
#20 0x00007f7bd2d0ea81 in ThreadWeaver::Thread::run (this=0x66fbee0) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/threadweaver/Weaver/Thread.cpp:142
#21 0x00007f7bd1465f22 in QThreadPrivate::start (arg=0x66fbee0) at thread/qthread_unix.cpp:189
#22 0x00007f7bd11f2070 in start_thread () from /lib64/libpthread.so.0
#23 0x00007f7bcf9b210d in clone () from /lib64/libc.so.6
#24 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f7bd48b8750 (LWP 12424)):
[KCrash Handler]
#5  0x00007f7bce881915 in KDevelop::BuilderJobPrivate::addJob (this=0x7f7bb2ab5b80, t=KDevelop::BuilderJob::Build, item=0x7f7bbdc90c10)
    at /home/kde-devel/kde/sources/trunk/KDE/kdevplatform/project/builderjob.cpp:61
#6  0x00007f7bce881c32 in KDevelop::BuilderJob::addItems (this=0x7f7bb146e890, t=KDevelop::BuilderJob::Build, items=@0x7fffdc900920)
    at /home/kde-devel/kde/sources/trunk/KDE/kdevplatform/project/builderjob.cpp:93
#7  0x00007f7baceba1b4 in BuildItemBuilderJob (this=0x7f7bb146e890, t=KDevelop::BuilderJob::Build, items=@0x7fffdc900920)
    at /home/kde-devel/kde/sources/trunk/KDE/kdevplatform/plugins/projectmanagerview/builditembuilderjob.cpp:39
#8  0x00007f7bacea8bda in ProjectManagerViewPlugin::runBuilderJob (this=0x671b3a0, t=KDevelop::BuilderJob::Build)
    at /home/kde-devel/kde/sources/trunk/KDE/kdevplatform/plugins/projectmanagerview/projectmanagerviewplugin.cpp:365
#9  0x00007f7bacea8c1c in ProjectManagerViewPlugin::buildProjectItems (this=0x671b3a0)
    at /home/kde-devel/kde/sources/trunk/KDE/kdevplatform/plugins/projectmanagerview/projectmanagerviewplugin.cpp:391
#10 0x00007f7baceaa405 in ProjectManagerViewPlugin::qt_metacall (this=0x671b3a0, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fffdc900a90)
    at /home/kde-devel/kde/build/trunk/KDE/kdevplatform/plugins/projectmanagerview/projectmanagerviewplugin.moc:105
#11 0x00007f7bd1564c22 in QMetaObject::activate (sender=0x5de49b0, from_signal_index=<value optimized out>, to_signal_index=6, argv=0x20) at kernel/qobject.cpp:3120
#12 0x00007f7bd054a777 in QAction::triggered (this=0x2293688, _t1=false) at .moc/release-shared/moc_qaction.cpp:236
#13 0x00007f7bd054bbf0 in QAction::activate (this=0x5de49b0, event=<value optimized out>) at kernel/qaction.cpp:1160
#14 0x00007f7bd054e707 in QAction::event (this=0x2293688, e=<value optimized out>) at kernel/qaction.cpp:1079
#15 0x00007f7bd1c09617 in KAction::event (this=0x5de49b0, event=0x7fffdc901010) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/kdeui/actions/kaction.cpp:88
#16 0x00007f7bd055078d in QApplicationPrivate::notify_helper (this=0x14ccb90, receiver=0x5de49b0, e=0x7fffdc901010) at kernel/qapplication.cpp:4057
#17 0x00007f7bd0558a2a in QApplication::notify (this=0x7fffdc9037e0, receiver=0x5de49b0, e=0x7fffdc901010) at kernel/qapplication.cpp:4022
#18 0x00007f7bd1cd94ad in KApplication::notify (this=0x7fffdc9037e0, receiver=0x5de49b0, event=0x7fffdc901010) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/kdeui/kernel/kapplication.cpp:302
#19 0x00007f7bd154f15c in QCoreApplication::notifyInternal (this=0x7fffdc9037e0, receiver=0x5de49b0, event=0x7fffdc901010) at kernel/qcoreapplication.cpp:610
#20 0x00007f7bd0585fdd in QShortcutMap::dispatchEvent (this=<value optimized out>, e=0x7fffdc901540) at ../../src/corelib/kernel/qcoreapplication.h:213
#21 0x00007f7bd0587e4c in QShortcutMap::tryShortcutEvent (this=0x14ccca8, o=<value optimized out>, e=0x7fffdc901540) at kernel/qshortcutmap.cpp:369
#22 0x00007f7bd0559a51 in QApplication::notify (this=0x7fffdc9037e0, receiver=0x8d144f0, e=0x7fffdc901540) at kernel/qapplication.cpp:3646
#23 0x00007f7bd1cd94ad in KApplication::notify (this=0x7fffdc9037e0, receiver=0x8d144f0, event=0x7fffdc901540) at /home/kde-devel/kde/sources/trunk/KDE/kdelibs/kdeui/kernel/kapplication.cpp:302
#24 0x00007f7bd154f15c in QCoreApplication::notifyInternal (this=0x7fffdc9037e0, receiver=0x8d144f0, event=0x7fffdc901540) at kernel/qcoreapplication.cpp:610
#25 0x00007f7bd05e45c4 in QKeyMapper::sendKeyEvent (keyWidget=0x8d144f0, grab=<value optimized out>, type=QEvent::KeyPress, code=16777271, modifiers={i = -594536592}, text=@0x7fffdc901760, 
    autorepeat=false, count=1, nativeScanCode=74, nativeVirtualKey=65477, nativeModifiers=16) at kernel/qkeymapper_x11.cpp:1678
#26 0x00007f7bd05e6932 in QKeyMapperPrivate::translateKeyEvent (this=0x150a590, keyWidget=0x8d144f0, event=0x7fffdc903370, grab=80) at kernel/qkeymapper_x11.cpp:1648
#27 0x00007f7bd05c073e in QApplication::x11ProcessEvent (this=0x7fffdc9037e0, event=0x7fffdc903370) at kernel/qapplication_x11.cpp:3457
#28 0x00007f7bd05e8384 in x11EventSourceDispatch (s=0x14d0350, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:146
#29 0x00007f7bc9ebc0fb in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#30 0x00007f7bc9ebf8cd in ?? () from /usr/lib64/libglib-2.0.so.0
#31 0x00007f7bc9ebfa8b in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#32 0x00007f7bd157889f in QEventDispatcherGlib::processEvents (this=0x614c30, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:324
#33 0x00007f7bd05e7b0f in QGuiEventDispatcherGlib::processEvents (this=0x2293688, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:202
#34 0x00007f7bd154d9f2 in QEventLoop::processEvents (this=<value optimized out>, flags={i = -594528672}) at kernel/qeventloop.cpp:149
#35 0x00007f7bd154ddbd in QEventLoop::exec (this=0x7fffdc9036a0, flags={i = -594528592}) at kernel/qeventloop.cpp:200
#36 0x00007f7bd15500a4 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888
#37 0x0000000000407769 in main (argc=1, argv=0x7fffdc904938) at /home/kde-devel/kde/sources/trunk/KDE/kdevelop/app/main.cpp:172
Comment 4 Andreas Pakulat 2009-06-28 14:37:14 UTC 
*** Bug 198154 has been marked as a duplicate of this bug. ***
Comment 5 Andreas Pakulat 2009-06-28 21:10:42 UTC 
*** Bug 198189 has been marked as a duplicate of this bug. ***
Comment 6 Dario Andres 2009-07-07 01:17:56 UTC 
*** Bug 199113 has been marked as a duplicate of this bug. ***
Comment 7 janitor048 2009-07-07 21:17:03 UTC 
Created attachment 35135 [details]
backtrace for crash when hitting F8 in order to compile project
Comment 8 janitor048 2009-07-07 21:17:55 UTC 
Can't somebody confirm this bug? It crashes on me quite frequently now, when trying to compile a project. Unfortunately I haven't been able to really pin it down to a certain pattern yet, seems quite random.
However, I think I haven't encountered these crashes until a few days ago (I'm on svn 992797 right now).

I've attached some more backtrace.
Comment 9 Christophe Marin 2009-07-07 22:10:56 UTC 
(In reply to comment #8)
> Can't somebody confirm this bug? 

The devs are aware of this issue, don't worry. The problem now is finding a reliable way to reproduce it.
Comment 10 Andreas Pakulat 2009-07-07 23:02:52 UTC 
Yeah, what I need is:

a) a reliable reproduction way (at least some steps that usually get you the crash)

b) the output from the terminal should also have some debug information if you activate the kdevplatform (project) debug area via kdebugdialog

One thing that would also be interesting is wether all of you are using release builds or wether someone is getting this with a debug build?

The reason I'm asking is because quite a couple of checks are done before the line in addJob() that is supposedly crashing. So if the code reaches that line (70) and crashes there this would indicate that either the backtrace is bogus or that its a release build where the Q_ASSERT's aren't triggered. If the latter is the case I definetly need the debug output.

Oh and I'll confirm this as soon as I can reproduce this myself, but of course anybody else with enough bugzilla rights can confirm it as well if he can reproduce it.
Comment 11 janitor048 2009-07-08 11:21:38 UTC 
Sorry guys, I didn't mean to be nagging. I was just a bit puzzled that this crash doesn't seem as common for other people as it is for me.

Anyway, I finally found a way to reliably reproduce the crash (on my machine at least). I'm on KDE 4.2.2 (64bit Ubuntu based installation) and have kdevelop and kdevplatform at svn 993014 right now. And yes, I think I'm using a release build - if that's the default type, I provided no extra DCMAKE_BUILD_TYPE information. I could also try with a debug build, but that would have to wait until this evening or tomorrow.

Here's how I can reproduce it (using these steps, I get the crash every time!):

1. Start kdevelop (no project, no files open)

2. Create new project from template (Project -> New from Template)
C++ -> No GUI (CMake) -> Simple CMake based...
default location, app name "test", build type set to release, no version control

3. Immediately close the project via Project -> Close All Projects
(also works if I open the "test" project and then do Project -> Close Project)

4. Re-open the project via Project -> Open Recent

5. Open the project tab on the left and just mark the "test" project (don't open any files or the like)

6. Hit F8 to build the project -> crash


I'll attach my backtrace and console output.


BTW: There is one superfluous dialog when creating the project (after the build directory dialogue) that is empty and just needs to be get rid off by clicking ok. But that's off topic here. 


Cheers, Oliver
Comment 12 janitor048 2009-07-08 11:22:59 UTC 
Created attachment 35147 [details]
backtrace for reproducible crash (see comment 11)
Comment 13 janitor048 2009-07-08 11:23:51 UTC 
Created attachment 35148 [details]
console output for reproducible crash (see comment 11)
Comment 14 Christophe Marin 2009-07-08 11:49:51 UTC 
Created attachment 35149 [details]
More console output

Verbose output with the steps from comment #11 and the debug areas turned on.
Comment 15 Armin Berres 2009-07-15 00:22:24 UTC 
Was just hit by this one with todays SVN.

Thread 1 (Thread 0x7f1136034760 (LWP 28766)):
[KCrash Handler]
#5  0x00007f1136f7a2d9 in KDevelop::BuilderJobPrivate::addJob (this=0x7f11104b2cc0, t=<value optimized out>, item=0x33941e0) at ../../project/builderjob.cpp:70
#6  0x00007f1136f7aa48 in KDevelop::BuilderJob::addItems (this=0x7f11116f1e40, t=KDevelop::BuilderJob::Build, items=<value optimized out>) at ../../project/builderjob.cpp:101
#7  0x00007f11309076f5 in ProjectManagerViewPlugin::runBuilderJob (this=0xa639a80, t=KDevelop::BuilderJob::Build) at ../../../plugins/projectmanagerview/projectmanagerviewplugin.cpp:390
#8  0x00007f113090be1d in ProjectManagerViewPlugin::qt_metacall (this=0xa639a80, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fff66d3c510) at ./projectmanagerviewplugin.moc:108
#9  0x0000003f9d567602 in QMetaObject::activate (sender=<value optimized out>, from_signal_index=<value optimized out>, to_signal_index=<value optimized out>, argv=<value optimized out>)
    at kernel/qobject.cpp:3112
#10 0x0000003b13fd18d7 in QAction::triggered (this=<value optimized out>, _t1=<value optimized out>) at .moc/release-shared/moc_qaction.cpp:236
#11 0x0000003b13fd2d50 in QAction::activate (this=<value optimized out>, event=<value optimized out>) at kernel/qaction.cpp:1160
#12 0x0000003b13fd580f in QAction::event (this=<value optimized out>, e=<value optimized out>) at kernel/qaction.cpp:1079
#13 0x0000003b16351403 in KAction::event (this=<value optimized out>, event=<value optimized out>) at ../../kdeui/actions/kaction.cpp:88
#14 0x0000003b13fd77ad in QApplicationPrivate::notify_helper (this=<value optimized out>, receiver=<value optimized out>, e=<value optimized out>) at kernel/qapplication.cpp:4056
#15 0x0000003b13fdf80a in QApplication::notify (this=<value optimized out>, receiver=<value optimized out>, e=<value optimized out>) at kernel/qapplication.cpp:4021
#16 0x0000003b16423a1b in KApplication::notify (this=<value optimized out>, receiver=<value optimized out>, event=<value optimized out>) at ../../kdeui/kernel/kapplication.cpp:302
#17 0x0000003f9d55249c in QCoreApplication::notifyInternal (this=<value optimized out>, receiver=<value optimized out>, event=<value optimized out>) at kernel/qcoreapplication.cpp:610
#18 0x0000003b1400c85d in QShortcutMap::dispatchEvent (this=<value optimized out>, e=<value optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:213
#19 0x0000003b1400e5dc in QShortcutMap::tryShortcutEvent (this=<value optimized out>, o=<value optimized out>, e=<value optimized out>) at kernel/qshortcutmap.cpp:369
#20 0x0000003b13fe07e9 in QApplication::notify (this=<value optimized out>, receiver=<value optimized out>, e=<value optimized out>) at kernel/qapplication.cpp:3645
#21 0x0000003b16423a1b in KApplication::notify (this=<value optimized out>, receiver=<value optimized out>, event=<value optimized out>) at ../../kdeui/kernel/kapplication.cpp:302
#22 0x0000003f9d55249c in QCoreApplication::notifyInternal (this=<value optimized out>, receiver=<value optimized out>, event=<value optimized out>) at kernel/qcoreapplication.cpp:610
#23 0x0000003b1406b184 in QKeyMapper::sendKeyEvent (keyWidget=<value optimized out>, grab=<value optimized out>, type=<value optimized out>, code=<value optimized out>, 
    modifiers=<value optimized out>, text=<value optimized out>, autorepeat=<value optimized out>, count=<value optimized out>, nativeScanCode=) at kernel/qkeymapper_x11.cpp:1675
#24 0x0000003b1406d459 in QKeyMapperPrivate::translateKeyEvent (this=<value optimized out>, keyWidget=<value optimized out>, event=<value optimized out>, grab=<value optimized out>)
    at kernel/qkeymapper_x11.cpp:1645
#25 0x0000003b1404644e in QApplication::x11ProcessEvent (this=<value optimized out>, event=<value optimized out>) at kernel/qapplication_x11.cpp:3443
#26 0x0000003b1406ee3c in x11EventSourceDispatch (s=<value optimized out>, callback=<value optimized out>, user_data=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:146
#27 0x0000003e02a39f7a in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#28 0x0000003e02a3d640 in ?? () from /usr/lib/libglib-2.0.so.0
#29 0x0000003e02a3d7dc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#30 0x0000003f9d57ab7f in QEventDispatcherGlib::processEvents (this=<value optimized out>, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:327
#31 0x0000003b1406e5ef in QGuiEventDispatcherGlib::processEvents (this=<value optimized out>, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:202
#32 0x0000003f9d550d62 in QEventLoop::processEvents (this=<value optimized out>, flags=<value optimized out>) at kernel/qeventloop.cpp:149
#33 0x0000003f9d551134 in QEventLoop::exec (this=<value optimized out>, flags=<value optimized out>) at kernel/qeventloop.cpp:201
#34 0x0000003f9d5533a4 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888
#35 0x0000000000407fbf in _start ()
Comment 16 Andreas Pakulat 2009-07-16 19:24:11 UTC 
(In reply to comment #15)
> Was just hit by this one with todays SVN.

Not reproduceable here, neither with the description, nor by trying to auto-reload a larger folder thats part of the buildset.

Unless someone finds reproduction steps that Aleix or myself can use to trigger this crash (or someone is able to reproduce and debug it) I'm closing this as fixed.
Comment 17 Milian Wolff 2009-08-11 18:17:40 UTC 
Still not working:

To reproduce do the following:

- Open any CMakeLists.txt in a Cmake project
- edit it
- hit F8 (but enable saving of files before building or save it before and hit f8 shorty after)

The problem is that in that case the project gets reloaded and the item we pass to the build job might get invalid
Comment 18 Andreas Pakulat 2009-08-11 20:08:45 UTC 
(In reply to comment #17)
> Still not working:
> 
> To reproduce do the following:
> 
> - Open any CMakeLists.txt in a Cmake project
> - edit it
> - hit F8 (but enable saving of files before building or save it before and hit
> f8 shorty after)
> 
> The problem is that in that case the project gets reloaded and the item we pass
> to the build job might get invalid

Well, I know the theory, but in practice I cannot reproduce this. No matter how hard I try, either there's something different between our two setups or this machine is too fast at reloading...

Do you maybe have multiple items in the buildset? Are you building the folder in which the CMakeLists.txt resides or are you building a subfolder or parent folder?
Comment 19 Milian Wolff 2009-08-12 18:04:57 UTC 
Maybe its important to have the CmakeLists.txt you are editing selected in the project view? Since then it tries to build that one. But if it was edited its item gets fubared.

- I have no buildsets at all
- I select the cmakelists.txt and hence try to build that (though it won't work of course...)
Comment 20 Andreas Pakulat 2009-09-06 17:36:15 UTC 
*** Bug 206384 has been marked as a duplicate of this bug. ***
Comment 21 Andreas Pakulat 2009-09-19 19:16:21 UTC 
*** Bug 207903 has been marked as a duplicate of this bug. ***
Comment 22 Andreas Pakulat 2009-09-25 08:22:23 UTC 
*** Bug 208450 has been marked as a duplicate of this bug. ***
Comment 23 Andreas Pakulat 2009-10-07 22:07:25 UTC 
*** Bug 209800 has been marked as a duplicate of this bug. ***
Comment 24 Andreas Pakulat 2009-10-08 19:34:59 UTC 
*** Bug 209878 has been marked as a duplicate of this bug. ***
Comment 25 Andreas Pakulat 2009-10-15 17:04:00 UTC 
*** Bug 210674 has been marked as a duplicate of this bug. ***
Comment 26 Andreas Pakulat 2009-10-21 09:28:22 UTC 
*** Bug 211274 has been marked as a duplicate of this bug. ***
Comment 27 Andreas Pakulat 2009-10-30 08:18:23 UTC 
*** Bug 212330 has been marked as a duplicate of this bug. ***
Comment 28 Andreas Pakulat 2009-11-06 00:57:15 UTC 
*** Bug 213350 has been marked as a duplicate of this bug. ***
Comment 29 Andreas Pakulat 2009-11-06 16:01:24 UTC 
*** Bug 213418 has been marked as a duplicate of this bug. ***
Comment 30 Andreas Pakulat 2009-11-11 09:25:43 UTC 
*** Bug 214076 has been marked as a duplicate of this bug. ***
Comment 31 Dario Andres 2009-11-12 13:55:24 UTC 
*** Bug 214234 has been marked as a duplicate of this bug. ***
Comment 32 Andreas Pakulat 2009-11-13 11:04:51 UTC 
*** Bug 214361 has been marked as a duplicate of this bug. ***
Comment 33 Olivier.jg 2009-11-21 08:13:19 UTC 
I am able to reliably reproduce this bug, and have tracked down what's happening.

Reproduction:
1. Make any CMake project.
2. Remove the project from the buildset
3. Select and open the CMakeLists.txt file from the project tree
4. Edit it
5. Save it
6. press F8
7. Crash

It shouldn't be time dependant.

What's happening is that when you first click on CMakeLists.txt, the selectionChanged event is triggered, and then the selectionController is updated, thus allowing runBuilderJob at projectmanagerviewplugin.cpp:393 to notice that there is a project item selected after it notices the buildset is empty.
Unfortunately, and here's the key to all this, when the project was reloaded, >>the selected item was deleted but the selectionChanged signal doesn't get emitted<<, and thus the selectionController wasn't updated.
So the selectionController is saying that it has a selected item, but the item it has is no longer valid (or selected, as you can see if you take a look at it before step 6). As soon as it tries to get the text of that item... fail.

The solution is probably to no longer call project->reloadModel directly, but to call it through the projectController, which can then emit a signal which can be slotted by the ProjectManagerView, which will duly update the selection.

Of course, this is all in kdevplatform, so I don't know if it isn't possible for Quanta to support, or if other bad things will happen if you can't call project->reloadModel() directly.
I also don't know if there's not a better way to do this, not being very familiar with Qt/KDE/kdevelop.

If that sounds good though, I can do it, just as long as I don't have to mess with Quanta.
Comment 34 Andreas Pakulat 2009-11-21 09:41:45 UTC 
First of all: Thanks for the thorough analysis.

I'm not convinced yet that this is the only problem, as I said before there's a possible race-condition between the buildset and the project-reloading too. Of course thats quite a lot harder to hit, especially on small projects.

Regarding a solution: I need to look closer into the possibilities. I don't think the project item should be deleted in the first place, or any other project item if its cmakelists.txt is being reloaded. Another thing is that we should get some kind of selection-changed or some other signal from QTreeView when the model does such changes...
Comment 35 David Nolden 2009-11-21 10:45:16 UTC 
@Andreas: But 'deleting' the item can still happen when something was _removed_ from the CMakeLists.txt, no? So "not deleting" the items would not fix the problem, rather it would just make it happen less often.

I propose the following solution for the project-item lifetime which is similar to the language-support "DeclarationId" object:

- Create an object "PersistentProjectItem" that only stores the path of the item as a QString, and has a .get() function in which it retrieves the item using the path.
- PersistentProjectItem has "operator bool()", "*", "->", operators and a "cast<..>()"
- Whenever a project-item is stored for a longer time, it has to be stored as PersistentProjectItem, and before using it, it has to be checked whether it's still valid.
Comment 36 Olivier.jg 2009-11-21 11:21:54 UTC 
In regard to not getting a selection-changed event, I was thinking that it had something to do with: http://doc.trolltech.com/4.5/qitemselectionmodel.html#selectionChanged
"note that this signal will not be emitted when the item model is reset."
However, even though the function is project::reloadModel, it's not the projectModel that's being reloaded, only the project. That means the problem is that removeRow doesn't emit selectionChanged when applicable. That would point to a problem with Qt's QStandardItemModel implementation of the function.
Comment 37 Olivier.jg 2009-11-21 12:24:37 UTC 
Re: Race Condition. Based on what Millan is saying, it sounds like there is one, but it should be fixed by updating the selection.
I cannot trigger this by editing a makefile and then building (with autosave enabled), only when I try to build again does it trigger. That means that the build always happens before the item is deleted for me (but not for him).
However, if the selection could be updated before the items get removed, that shouldn't be an issue.
This could be as simple as overriding the RemoveRows function to emit selectionChanged before doing it's work. Or it could not... I can't say I'm intimate with the details involved.
Comment 38 Andreas Pakulat 2009-11-21 12:39:16 UTC 
(In reply to comment #35)
> @Andreas: But 'deleting' the item can still happen when something was _removed_
> from the CMakeLists.txt, no? So "not deleting" the items would not fix the
> problem, rather it would just make it happen less often.
> 
> I propose the following solution for the project-item lifetime which is similar
> to the language-support "DeclarationId" object:
> 
> - Create an object "PersistentProjectItem" that only stores the path of the
> item as a QString, and has a .get() function in which it retrieves the item
> using the path.
> - PersistentProjectItem has "operator bool()", "*", "->", operators and a
> "cast<..>()"
> - Whenever a project-item is stored for a longer time, it has to be stored as
> PersistentProjectItem, and before using it, it has to be checked whether it's
> still valid.

We actually already do that where needed. Except that its called "BuildSetItem", but it does the same thing.

And that wouldn't necessarily help in this case, the path of the selection may get invalid when the reloading happens. So what we really need is to check if there's a bug in Qt's model that if the currently selected row is removed there's no selectionChanged signal (which should be emitted) and then workaround that bug (and report upstream).
Comment 39 David Nolden 2009-11-21 13:16:00 UTC 
@Andreas: Then that BuildSetItem thing should be public API and used in more places, as exactly the same problem exists for example in the new-class wizard.

If a path gets invalidated after reloading, the item could just return zero, and the invalidation should be noticed instead of crashing. Then the problem you're dealing with here would be a warning instead of a crash. ;-)
Comment 40 Andreas Pakulat 2009-11-21 13:32:26 UTC 
(In reply to comment #39)
> @Andreas: Then that BuildSetItem thing should be public API

It already is, see project/buildsetmodel.h

> and used in more
> places, as exactly the same problem exists for example in the new-class wizard.

How? The class wizard is a modal dialog, one cannot delete an item behind its back. 

Anyway, if we want to use that in more places we need to rename the BuildItem class to something else.

> If a path gets invalidated after reloading, the item could just return zero,
> and the invalidation should be noticed instead of crashing. Then the problem
> you're dealing with here would be a warning instead of a crash. ;-)

Or have it as a Q_ASSERT or something. At least it would crash further up in the usual stacktraces..
Comment 41 Olivier.jg 2009-11-21 22:41:47 UTC 
Few things of note:
Looked at QT's source, doesn't look like they emit selectionChanged in their removeRows, but they do give a rowsAboutToBeRemoved, which should suffice for a workaround.
The item itself is difficult to track, but at the point where it gets to addJob, the item is not null (thereby passes Q_ASSERTs), but it's clearly corrupted/overwritten.
If this problem is fixed by the selectionController being updated properly, when someone edits the CMakeLists.txt file, and presses F8, the file will save, and then the build will silently be cancelled since there's no item selected. They'd have to save, wait for reload, reselect CMakeLists, and then build.
In other words, it sounds like the build just needs to wait for the reload to finish.
Comment 42 Olivier.jg 2009-11-22 01:47:51 UTC 
Unless it's possible in all circumstances for the reload to wait for the build...
Comment 43 Thorben Kröger 2009-11-22 16:35:00 UTC 
(In reply to comment #40)
> (In reply to comment #39)
> How? The class wizard is a modal dialog, one cannot delete an item behind its
> back. 

Don't forget that the user can also "rm" files from the command line. I often switch between command line and kdevelop usage, so this happens more often than one might think...
Comment 44 David Nolden 2009-11-22 17:32:30 UTC 
> How? The class wizard is a modal dialog, one cannot delete an item behind its
> back. 

1. It is modal, but the event-loop still continues, so the cmake manager may delete items at will during arbitrarily triggered updates.
2. The class-wizard, when used with cmake, may trigger
Comment 45 David Nolden 2009-11-22 17:34:31 UTC 
> How? The class wizard is a modal dialog, one cannot delete an item behind its
> back. 

1. It is modal, but the event-loop still continues, so the cmake manager may delete items at will during arbitrarily triggered updates.
2. The class-wizard, when used with cmake, may open an editor that allows the user to add new created files to the CMakeLists.txt, and an update may be triggered from there.
Comment 46 Andreas Pakulat 2009-11-25 15:11:19 UTC 
*** Bug 216090 has been marked as a duplicate of this bug. ***
Comment 47 Olivier.jg 2009-11-26 08:27:07 UTC 
Created attachment 38596 [details]
Make it stop crashing

This will make the projectmanagerview update the selection before removing rows, which will keep the selectionController current, which should fix this problem.
This should probably be done regardless of any BuildSetItem changes, as it's a workaround for qt not updating the selection when rows are removed.
Comment 48 Hamish Rodda 2009-11-26 15:24:16 UTC 
I've applied your patch locally, will tell you if I hit the bug in the next few days or not...
Comment 49 Andreas Pakulat 2009-11-26 21:19:14 UTC 
(In reply to comment #47)
> This will make the projectmanagerview update the selection before removing
> rows, which will keep the selectionController current, which should fix this
> problem.
> This should probably be done regardless of any BuildSetItem changes, as it's a
> workaround for qt not updating the selection when rows are removed.

I just committed this and was about to file a bugreport with Qt, but I actually can't reproduce what you're saying. Its correct that the model doesn't emit a selectionChanged signal, but thats quite normal. The model doesn't have a selection, instead the treeview is the one that should emit the selection.
Comment 50 Hamish Rodda 2009-11-27 02:16:22 UTC 
Actually I was seeing a different issue (which hasn't been fixed by the patch)...
Comment 51 Olivier.jg 2009-11-27 05:09:01 UTC 
> I just committed this and was about to file a bugreport with Qt, but I actually
> can't reproduce what you're saying. Its correct that the model doesn't emit a
> selectionChanged signal, but thats quite normal. The model doesn't have a
> selection, instead the treeview is the one that should emit the selection.

A good point, I was mistaken about a couple things. But actually it's not the treeview but the selectionModel that should emit the selectionChanged event.

The good news is that the QItemSelectionModel actually does emit the selectionChanged event when it's Model emits rowsAboutToBeRemoved(), which I didn't realize before.
However, what is in use is not a QStandardItemModel but a ProjectProxyModel (inheriting from QAbstractProxyModel).
The problem is that the ProjectProxyModel to which the ProxySelectionModel is bound doesn't emit rowsAboutToBeRemoved(). The sourceModel() of the ProjectProxyModel does, but the ProjectProxyModel itself doesn't, which makes sense, but does end up causing this bug.

There are two workarounds off the top of my head:
1. The patch I already provided is a simple enough workaround
2. The ProxySelectionModel could connect to the rowsAboutToBeRemoved of the sourceModel() of it's QAbstractProxyModel, and then emit selectionChanged accordingly. (effectively identical to the patch I provided)

All that to say, I would still consider this a Qt bug, because Any selectionModel that uses a QAbstractProxyModel derivative won't get a rowsAboutToBeRemoved signal, and will so be as broken as we are seeing.
Comment 52 Andreas Pakulat 2009-12-04 12:55:15 UTC 
*** Bug 217323 has been marked as a duplicate of this bug. ***
Comment 53 Andreas Pakulat 2009-12-17 19:29:02 UTC 
*** Bug 219089 has been marked as a duplicate of this bug. ***
Comment 54 Olivier.jg 2009-12-29 03:46:36 UTC 
Can this still be reproduced in any way with current trunk?
Comment 55 Andreas Pakulat 2010-01-16 09:05:10 UTC 
*** Bug 222926 has been marked as a duplicate of this bug. ***
Comment 56 Andreas Pakulat 2010-01-16 12:04:06 UTC 
*** Bug 222957 has been marked as a duplicate of this bug. ***
Comment 57 Andreas Pakulat 2010-03-03 07:40:21 UTC 
*** Bug 229187 has been marked as a duplicate of this bug. ***
Comment 58 Andreas Pakulat 2010-03-22 00:57:05 UTC 
*** Bug 231607 has been marked as a duplicate of this bug. ***
Comment 59 Andreas Pakulat 2010-04-15 19:29:49 UTC 
*** Bug 234450 has been marked as a duplicate of this bug. ***
Comment 60 Andreas Pakulat 2010-06-03 11:17:07 UTC 
*** Bug 240568 has been marked as a duplicate of this bug. ***
Comment 61 Gunther Piez 2010-10-22 11:18:20 UTC 
Created attachment 52750 [details]
New crash information added by DrKonqi

kdevelop (4.1.60) on KDE Platform 4.5.2 (KDE 4.5.2) using Qt 4.6.3

- What I was doing when the application crashed:

I hit the "build selection" button. Kdevelop/platform build from todays git. It is now crashing every time, "configure selection" crashes too.

-- Backtrace (Reduced):
#6  0x00007fa1194e2889 in KDevelop::BuilderJobPrivate::addJob (this=0x631aa10, t=<value optimized out>, item=0x1b9e820) at /home/gpiez/src/kdevplatform/project/builderjob.cpp:70
#7  0x00007fa0fad91461 in BuildItemBuilderJob::BuildItemBuilderJob (this=0x617afb0, t=KDevelop::BuilderJob::Build, items=...) at /home/gpiez/src/kdevplatform/plugins/projectmanagerview/builditembuilderjob.cpp:35
#8  0x00007fa0fad864b8 in ProjectManagerViewPlugin::runBuilderJob (this=<value optimized out>, t=KDevelop::BuilderJob::Build) at /home/gpiez/src/kdevplatform/plugins/projectmanagerview/projectmanagerviewplugin.cpp:339
#9  0x00007fa0fad89adc in ProjectManagerViewPlugin::qt_metacall (this=0x1287cc0, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fff3ff1b520) at /home/gpiez/src/kdevplatform/build/plugins/projectmanagerview/projectmanagerviewplugin.moc:109
[...]
#11 0x00007fa11b790982 in QAction::triggered (this=<value optimized out>, _t1=false) at .moc/debug-shared/moc_qaction.cpp:263
Comment 62 Gunther Piez 2010-10-22 11:38:00 UTC 
Just tried it again, with a debug build and the crash went away. Looks like a heisenbug. At least I got some additional information from stderr, which weren't present in the crashed before:

Object::disconnect: Unexpected null parameter
Object::disconnect: Unexpected null parameter
... (repeat severeal times)
Object::connect: No such signal KDevelop::CommandExecutor::failed( QProcess::Error ) in /home/gpiez/src/kdevelop/projectbuilders/cmakebuilder/cmakejob.cpp:102
Object::connect:  (receiver name: 'CMake: myprojectname')
Comment 63 Andrew Crouthamel 2018-09-20 22:12:58 UTC 
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 64 Andrew Crouthamel 2018-10-21 04:50:18 UTC 
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!