kdevelop hangs on close?

Andreas Pakulat apaku at gmx.de
Wed Jun 25 17:58:41 UTC 2008


On 25.06.08 11:56:00, Matthew Woehlke wrote:
> I've noticed that when I close kdevelop, often the process doesn't go 
> away. This morning I noticed I have another zombie, so I attached with 
> gdb and got this:

Noticed that too actually, so when I said I don't see that on IRC it was
a misunderstanding (I thought it would go zombie during normal usage).

> (gdb) thread apply all bt
> 
> Thread 2 (Thread 1105430864 (LWP 31750)):
> #0  0x000000313440a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x00007f3d70528b33 in QWaitConditionPrivate::wait (this=0xaf4790, 
> time=18446744073709551615) at 
> /usr/local/src/kde/svn/trunk/qt-copy/src/corelib/thread/qwaitcondition_unix.cpp:88
> #2  0x00007f3d70528692 in QWaitCondition::wait (this=0xaf4618, 
> mutex=0xaf49b0, time=18446744073709551615) at 
> /usr/local/src/kde/svn/trunk/qt-copy/src/corelib/thread/qwaitcondition_unix.cpp:265
> #3  0x00007f3d6d8bdf01 in 
> ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned 
> (this=0xaf45f0, th=0x2453d10)
>      at 
> /usr/local/src/kde/svn/trunk/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:365
> #4  0x00007f3d6d8c2637 in 
> ThreadWeaver::WorkingHardState::waitForAvailableJob (this=0xaf4a90, 
> th=0x2453d10) at 
> /usr/local/src/kde/svn/trunk/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:80
> #5  0x00007f3d6d8bd64a in ThreadWeaver::WeaverImpl::waitForAvailableJob 
> (this=0xaf45f0, th=0x2453d10) at 
> /usr/local/src/kde/svn/trunk/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:356
> #6  0x00007f3d6d8c272f in ThreadWeaver::WorkingHardState::applyForWork 
> (this=0xaf4a90, th=0x2453d10) at 
> /usr/local/src/kde/svn/trunk/kdelibs/threadweaver/Weaver/WorkingHardState.cpp:71
> #7  0x00007f3d6d8be13d in ThreadWeaver::WeaverImpl::applyForWork 
> (this=0xaf45f0, th=0x2453d10, previous=0x28edc60) at 
> /usr/local/src/kde/svn/trunk/kdelibs/threadweaver/Weaver/WeaverImpl.cpp:351
> #8  0x00007f3d6d8c09ba in ThreadWeaver::ThreadRunHelper::run 
> (this=0x41e38050, parent=0xaf45f0, th=0x2453d10) at 
> /usr/local/src/kde/svn/trunk/kdelibs/threadweaver/Weaver/Thread.cpp:87
> #9  0x00007f3d6d8c0b19 in ThreadWeaver::Thread::run (this=0x2453d10) at 
> /usr/local/src/kde/svn/trunk/kdelibs/threadweaver/Weaver/Thread.cpp:142
> #10 0x00007f3d7052832a in QThreadPrivate::start (arg=0x2453d10) at 
> /usr/local/src/kde/svn/trunk/qt-copy/src/corelib/thread/qthread_unix.cpp:190
> #11 0x0000003134406407 in start_thread () from /lib64/libpthread.so.0
> #12 0x00000031338d4b0d in clone () from /lib64/libc.so.6
> 
> Thread 1 (Thread 139901767943936 (LWP 31456)):
> #0  0x000000313440cebe in __lll_lock_wait_private () from 
> /lib64/libpthread.so.0
> #1  0x000000313440a614 in _L_lock_20 () from /lib64/libpthread.so.0
> #2  0x000000313440a3cb in pthread_cond_destroy@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #3  0x00007f3d70527323 in ~QMutexPrivate (this=0x2036f70) at 
> /usr/local/src/kde/svn/trunk/qt-copy/src/corelib/thread/qmutex_unix.cpp:72
> #4  0x00007f3d705223fb in ~QMutex (this=0x7f3d6c147910) at 
> /usr/local/src/kde/svn/trunk/qt-copy/src/corelib/thread/qmutex.cpp:135
> #5  0x00007f3d6beae06e in __tcf_0 () at 
> /usr/local/src/kde/svn/trunk/kdevplatform/language/editor/documentrangeobject.cpp:251
> #6  0x000000313383432d in __cxa_finalize () from /lib64/libc.so.6
> #7  0x00007f3d6beac926 in __do_global_dtors_aux () from 
> /usr/local/kde-trunk-svn/lib64/libkdevplatformlanguage.so.4
> #8  0x0000000000000000 in ?? ()
> #0  0x000000313440cebe in __lll_lock_wait_private () from 
> /lib64/libpthread.so.0

Looks like a lookup in the duchain stuff of CPP. Was it still parsing
something when you exited? (i.e. was the progressbar visible)

David hopefully knows more.

Andreas

-- 
Everything that you know is wrong, but you can be straightened out.




More information about the KDevelop-devel mailing list