Version: 3.0.4 (using KDE 3.2.3, compiled sources) Compiler: gcc version 3.3.3 OS: Linux (i686) release 2.6.6 I'm having a problem with KDevelop hanging when I close a project or close the application itself. This happens without fail every time I do this. Using strace I noticed that KDevelop is being forced to wait on a futex - it seems like it's not being scheduled to run again. Here's the strace output: open("/home/gareth/code/rollercoaster/rollercoaster.kdevelop.pcs", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 12 fstat64(12, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 open("/home/gareth/code/rollercoaster/rollercoaster.kdevelop.ignore_pcs", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 13 fstat64(13, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 fstat64(13, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x43944000 write(13, "ignore me\n\0", 11) = 11 close(13) = 0 munmap(0x43944000, 4096) = 0 fstat64(12, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x43944000 write(12, "\0\0\0\6\0P\0C\0S\0\0\0\5\0\0\0\2\0\0\0j\0/\0h\0o\0m\0"..., 1690) = 1690 _llseek(12, 132, [132], SEEK_SET) = 0 write(12, "\0\0\0\372", 4) = 4 _llseek(12, 1690, [1690], SEEK_SET) = 0 write(12, "\0\0\0\1\0\0\0f\0/\0h\0o\0m\0e\0/\0g\0a\0r\0e\0t\0h"..., 576) = 576 _llseek(12, 246, [246], SEEK_SET) = 0 write(12, "\0\0\6\232", 4) = 4 _llseek(12, 2266, [2266], SEEK_SET) = 0 unlink("/home/gareth/code/rollercoaster/rollercoaster.kdevelop.ignore_pcs") = 0 close(12) = 0 munmap(0x43944000, 4096) = 0 futex(0x841ba68, FUTEX_REQUEUE, 1, 2147483647, 0x416a62a8) = 1 futex(0x8ab620c, FUTEX_WAIT, 0, NULL) = -1 EINTR (Interrupted system call) +++ killed by SIGKILL +++ As you can see that I had to kill Kdevelop, using the KDE "This application has stopped responding..." dialogue. I hope this report is helpful - if there's any more information I can give you I'll be happy to help.
Im having this too, kdevelop crashes when closing project or when closing app (if project is open). gcc-3.4.2 kdelibs + kdevelop sources from CVS
ASSERT: "part && parent" in partwidget.cpp (41) kio (KDirWatch): WARNING: KDirWatch::removeDir can't handle '/home/bonkie/Projects/APG' kio (KDirWatch): WARNING: KDirWatch::removeDir can't handle '/home/bonkie' kio (KDirWatch): WARNING: KDirWatch::removeDir can't handle '/home/bonkie/Projects' kio (KDirWatch): WARNING: KDirWatch::removeDir can't handle ''
Is this still valid?
Yes it is. It still happens to me with Kdevelop version 3.1.2, compiled with gcc 3.3.3.
Still happened on kdevelop-3.1.2 with kde-3.3.* and kdevelop-3.2.0 with kde-3.4.0 RC 1 Both have been compiled with gcc-3.4.3 with options "-march=athlon-xp -O3"
This is caused by the call to QThread::exit in the languages/cpp/BackgroundParser.cpp run() method. In Qt, this doesn't cause QThread::running() to return false (a Qt bug?), but does terminate the thread. Removing the call to QThread::exit lets run() finish, and lets QThread update its running variable, so that BackgroundParser::close()'s loop will terminate. I'd attach a patch, only I don't have the code handy at the moment, and it's a one-line delete anyway.
*** This bug has been confirmed by popular vote. ***
I guess for this bug to still be around after six months it wasn't just a simple one-line fix after all?? I have the same behaviour upon closing projects with KDevelop 3.2.2 on KDE 3.4.2 (Fedora Core 4 update release).
Please retest with KDevelop 3.2.90
Amilcar do Carmo Lucas wrote: [bugs.kde.org quoted mail] So far it seems more stable... I'll test it extensively over the next few days and if all seems well, I'll post a note on bugzilla. Cheers, Ross
I've been running 3.2.90 on KDE 3.4.90 for a couple of weeks now and this still happens about 90% of the times I close a project. Kdevelop closes a couple of files that are open, and then just hangs forever. Compiled with gcc 3.2.2, running on Red Hat 8, 2.4.20-8smp (HT P4). This does not happen if I just open and close the project, or even if I open the project, open a few files, close a few, and then close the project. But it always happens if I've had the project open for a while, and opened, and closed, and edited files.
KDevelop 3.2.90 has just crashed on me after closing a project... the bug is clearly still present.
I should also mention that the symptoms are identical to those noted by the previous poster, and I compiled KDevelop with gcc-4.0.1, and I'm using KDE 3.4.2 on an updated Fedora Core 4 system (2.6.11 kernel).
I'm facing the same problem. kdevelop 3.2.91, KDE 3.4.2-0 fc4.1 and QT 4.0.1 It always fails to close the project. Please let me know if you need any more information graeme.
The solution to this bug is very simple, remove the line QThread::exit() from languages/cpp/BackgroundParser.cpp (it should also be removed from languages/java/BackgroundParser.cpp). Making this single change on SVN eliminates the problem, it even seems like this was fixed in SVN for a time, but in the recent betas it reappears, why? Who's in charge here?
Created attachment 13131 [details] Patch to fix kdevelop hanging on close This fixes kdevelops hang when closing a project containing c++ or java
Yes, the above patch from Dan seems to fix the issue for me. Thanks Dan.
Hi, the patch however seems not to be in SVN for KDE 3.5.0: http://websvn.kde.org/branches/KDE/3.5/kdevelop/languages/cpp/backgroundparser.cpp?rev=438982&view=rev
Sorry, the link should be http://websvn.kde.org/branches/KDE/3.5/kdevelop/languages/cpp/backgroundparser.cpp?rev=438982&view=markup
SVN commit 518689 by dymo: BUG: 83352 M +2 -1 backgroundparser.cpp --- branches/kdevelop/3.4/languages/java/backgroundparser.cpp #518688:518689 @@ -359,5 +359,6 @@ kdDebug(9013) << "!!!!!!!!!!!!!!!!!! BG PARSER DESTROYED !!!!!!!!!!!!" << endl; - QThread::exit(); + //commented to fix #83352 + //QThread::exit(); }
Hi, Megan Webb and two other kdevelop user still experience this thing, Megan produced backtraces, which I will attach.
This is the backtrace from the main thread: #0 0xffffe410 in __kernel_vsyscall () #1 0xb5f2c8d6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb63c7521 in QThread::wait (this=0x8669130, time=4294967295) at kernel/qthread_unix.cpp:460 #3 0xb4a8bc92 in ~UIBlockTester (this=0x8669108) at cppsupportpart.cpp:3159 #4 0xb4a9f7ce in ~CppSupportPart (this=0x8678058) at cppsupportpart.cpp:321 #5 0xb7f5cfe2 in ProjectManager::unloadLanguageSupport (this=0x8177c70) at projectmanager.cpp:576 #6 0xb7f60137 in ProjectManager::closeProject (this=0x8177c70, exiting=false) at projectmanager.cpp:330 #7 0xb7f613c9 in ProjectManager::qt_invoke (this=0x8177c70, _id=4, _o=0xbf9a591c) at projectmanager.moc:115 #8 0xb6444a2f in QObject::activate_signal (this=0x8179610, clist=0x817a3c8, o=0xbf9a591c) at kernel/qobject.cpp:2356 #9 0xb64457c8 in QObject::activate_signal (this=0x8179610, signal=2) at kernel/qobject.cpp:2325 #10 0xb6f2c5ce in KAction::activated (this=0x8179610) at kaction.moc:176 #11 0xb6f2cdf1 in KAction::slotActivated (this=0x8179610) at kaction.cpp:1102 #12 0xb6f2d04c in KAction::slotPopupActivated (this=0x8179610) at kaction.cpp:1137 #13 0xb6f2d3a4 in KAction::qt_invoke (this=0x8179610, _id=16, _o=0xbf9a5a78) at kaction.moc:219 #14 0xb6444a2f in QObject::activate_signal (this=0x8197a80, clist=0x818b7a0, o=0xbf9a5a78) at kernel/qobject.cpp:2356 #15 0xb684203f in QSignal::signal (this=0x8197a80, t0=@0x8197aa8) at .moc/debug-shared-mt/moc_qsignal.cpp:100 #16 0xb6468cbb in QSignal::activate (this=0x8197a80) at kernel/qsignal.cpp:212 #17 0xb658d068 in QPopupMenu::mouseReleaseEvent (this=0x81995f0, e=0xbf9a5fc4) at widgets/qpopupmenu.cpp:1691 #18 0xb6f1b587 in KPopupMenu::mouseReleaseEvent (this=0x81995f0, e=0xbf9a5fc4) at kpopupmenu.cpp:508 #19 0xb64856f7 in QWidget::event (this=0x81995f0, e=0xbf9a5fc4) at kernel/qwidget.cpp:4677 #20 0xb63d01bb in QApplication::internalNotify (this=0xbf9a6614, receiver=0x81995f0, e=0xbf9a5fc4) at kernel/qapplication.cpp:2635 #21 0xb63d24b9 in QApplication::notify (this=0xbf9a6614, receiver=0x81995f0, e=0xbf9a5fc4) at kernel/qapplication.cpp:2421 #22 0xb6c425eb in KApplication::notify (this=0xbf9a6614, receiver=0x81995f0, event=0xbf9a5fc4) at kapplication.cpp:550 #23 0xb6359cf5 in QApplication::sendSpontaneousEvent (receiver=0x81995f0, event=0xbf9a5fc4) at kernel/qapplication.h:499 #24 0xb635864b in QETWidget::translateMouseEvent (this=0x81995f0, event=0xbf9a6468) at kernel/qapplication_x11.cpp:4240 #25 0xb6356aec in QApplication::x11ProcessEvent (this=0xbf9a6614, event=0xbf9a6468) at kernel/qapplication_x11.cpp:3449 #26 0xb636f90e in QEventLoop::processEvents (this=0x807eec0, flags=4) at kernel/qeventloop_x11.cpp:192 #27 0xb63ee1d5 in QEventLoop::enterLoop (this=0x807eec0) at kernel/qeventloop.cpp:198 #28 0xb63edff6 in QEventLoop::exec (this=0x807eec0) at kernel/qeventloop.cpp:145 #29 0xb63d1e7f in QApplication::exec (this=0xbf9a6614) at kernel/qapplication.cpp:2758 #30 0x0804ef17 in main (argc=-16777216, argv=0xff000000) at main.cpp:143
Here's the backtrace from the second thread: #0 0xffffe410 in __kernel_vsyscall () #1 0xb5f0a8d6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb6763484 in QWaitCondition::wait (this=0x8875ba0, time=4294967295) at tools/qwaitcondition_unix.cpp:242 #3 0xb45983f4 in BackgroundParser::run (this=0x8875b90) at backgroundparser.cpp:520 #4 0xb63a598f in QThreadInstance::start (_arg=0x88a0904) at kernel/qthread_unix.cpp:119 #5 0xb5f064bb in start_thread () from /lib/libpthread.so.0 #6 0xb5c7377e in clone () from /lib/libc.so.6
This is hopefully fixed in current svn.
This bug is not fixed in v3.4.1. I did not have any problems with v3.4.0 (or any prior versions). But now with this version, I am having the same problems. KDevelop simply freezes when closing projects (or when exiting with open projects). There's no back-trace or crash dialog. I have tested for Qt4, Qt3 and simple C++ projects and the problem is present with all three. ---------------------------------------- KDevelop v3.4.1, KDE v3.5.6-9.fc7, Fedora 7 Compiled KDevelop from sources: ./configure --disable-ada --disable-bash --disable-fortran --disable-haskell --disable-java --disable-csharp --disable-pascal --disable-perl --disable-php --disable-ruby --disable-sql --disable-clearcase --disable-perforce --disable-vba --disable-subversion
More information: strace output (last few lines..) ----------------------------------- access("/tmp/kde-root/kdevelopgYT49w/", F_OK) = 0 lstat64("/tmp/kde-root/kdevelopgYT49w/", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 open("/tmp/kde-root/kdevelopgYT49w/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 23 fstat64(23, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 fcntl64(23, F_SETFD, FD_CLOEXEC) = 0 getdents64(23, /* 2 entries */, 4096) = 48 getdents64(23, /* 0 entries */, 4096) = 0 close(23) = 0 rmdir("/tmp/kde-root/kdevelopgYT49w/") = 0 ioctl(6, FIONREAD, [1]) = 0 gettimeofday({1181754341, 714121}, NULL) = 0 gettimeofday({1181754341, 715563}, NULL) = 0 gettimeofday({1181754341, 716764}, NULL) = 0 ioctl(6, FIONREAD, [1]) = 0 gettimeofday({1181754341, 717830}, NULL) = 0 ioctl(6, FIONREAD, [1]) = 0 gettimeofday({1181754341, 776971}, NULL) = 0 ioctl(6, FIONREAD, [1]) = 0 gettimeofday({1181754341, 778126}, NULL) = 0 gettimeofday({1181754341, 778433}, NULL) = 0 gettimeofday({1181754341, 779040}, NULL) = 0 gettimeofday({1181754341, 779970}, NULL) = 0 tgkill(11709, 11744, SIGRTMIN) = 0 futex(0x8f9bfe0, FUTEX_WAIT, 1, NULL ---------------------------------------------------------
David said its fixed in svn and looking at the time he said this its clear that the change didn't make it into 3.4.1. If you want to check this you have to build KDevelop yourself from svn, instructions are on our website.