Version: CVS (using KDE 3.3.89 (CVS >= 20040820), compiled sources) Compiler: gcc version 3.4.0 OS: Linux (i686) release 2.4.22-10mdk A guy came on IRC and said he could not import gdb-6.2 in kdevelop. I download gdb-6.2 sources, untarred them and run KDevelop Import tool. After I selected the directory gdb-6.2, the import dialog set itself on automake C project and I imported successfully. However, I retried to import as Custom Makefile and then KDevelop ate all CPU and I got stuck, had to hard reboot. So it seems that importing a Custom Makefile project is causing memory leak.
I'm the IRC guy... here is the big picture. I want to use kdevelop for some non automake projects. Stuff that doesn't run on Linux, ie we are cross compiling and downloading onto a target... long story. We just want to use a simple make system and we don't want to use automake for our simple project. We'd like to import some existing projects that use what kdev calls "custom makefiles". I also have some devel work to do on gdb, building a custom stub for it to work with our target. So... I wanted to work on gdb-6.2 in kdev to test it out a bit. I wanted to import the gdb-6.2 proj as a custom makefile project to work on it in kdev. I'm running on various Fedora Core distros. I started on FC2, but it gave me errors, so I moved to FC3, thinking the KDE libs would be newer and better tested. I've tried kde 3.1.1 from rpms and from building on my machine. I've also tried building the 041101 development tars. In all these cases, I cannot import a custom makefile project. I get the same error that the annma gets, ie kdev hangs. annma can import a project as automake, I cannot. When I try to import as autmake, Kdev 041101 (built on my machine from tars) crashes with the following: Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -155396416 (LWP 16515)] [New Thread -168629328 (LWP 16517)] [Thread debugging using libthread_db enabled] [New Thread -155396416 (LWP 16515)] [New Thread -168629328 (LWP 16517)] [Thread debugging using libthread_db enabled] [New Thread -155396416 (LWP 16515)] [New Thread -168629328 (LWP 16517)] [KCrash handler] #4 0x0394ad8f in QGArray::QGArray () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #5 0x00388258 in DCOPStub::obj () from /usr/lib/libDCOP.so.4 #6 0x00203d2b in Repository_stub::location () from /usr/lib/libcvsservice.so.0 #7 0xf5febfbf in CvsServicePartImpl::slotProjectOpened () from /usr/lib/kde3/libkdevcvsservice.so #8 0xf5fec3d5 in CvsServicePartImpl::qt_invoke () from /usr/lib/kde3/libkdevcvsservice.so #9 0x036a3329 in QObject::activate_signal () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #10 0x036a3a7a in QObject::activate_signal () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #11 0x080ae9fc in KDevCore::projectOpened () #12 0x0808207c in QPtrList<KParts::Part>::deleteItem () #13 0x08085080 in QPtrList<KParts::Part>::deleteItem () #14 0x036a33a0 in QObject::activate_signal () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #15 0x039d459d in QSignal::signal () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #16 0x036bc0dd in QSignal::activate () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #17 0x036c319b in QSingleShotTimer::event () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #18 0x03644849 in QApplication::internalNotify () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #19 0x036449da in QApplication::notify () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #20 0x004954e8 in KApplication::notify () from /usr/lib/libkdecore.so.4 #21 0x03638bbe in QEventLoop::activateTimers () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #22 0x035f4bde in QEventLoop::processEvents () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #23 0x03659e75 in QEventLoop::enterLoop () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #24 0x03659dce in QEventLoop::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #25 0x03643a4b in QApplication::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #26 0x080a23aa in KMdiMainFrm::tileVertically () #27 0xf6cb2e33 in __libc_start_main () from /lib/tls/libc.so.6 #28 0x08072561 in ?? () Other operations crash in different ways. I'll provide more details when someone takes up this issue. I am trying to run kdev INSIDE of gdb, so that I can get a better feel for what is happening. (Right now I think that a bad pointer is being passed to memcpy in line 331 of customprojectpart.cpp, which goes something like this: m_sourceFiles.append(path.mid(prefixlen)) However, that is just a guess at this point because... I CANNOT GET THE KDEV SYMBOLS TO APPEAR IN GDB !!! For example, I am trying to run as follows: "gdb ./kdevelop" When I am in gdb, I would like to see the source code symbols of kdev so that I can set breakpoints and step through the code and find the problem. I am building kdev with --debug=full and I've gone into the configure.m4 file and changed cxxflags to -g, -g3, -ggdb, etc. I cannot get the kdev symbols to appear in gdb. Another thing: I am not getting good info from the kdev asserts in the code either. Is there something I need to set that will flush the stream buffers once in a while so that I get a frequent update on the asserts while it is crashing ? I am using kdebug-dialog to set up the viewing of the asserts. I am very frustrated with all of this. Any help will be greatly appreciated.
Here is the command line feedback from running 041101 built on my machine from tars. I am trying to import the project as automake. $ kdevelop QLayout "unnamed" added to IndexView "unnamed", which already has a layout QObject::connect: No such slot ImportDialog::slotFetchModulesFromRepository() QObject::connect: (sender name: 'fetchModuleButton') QObject::connect: (receiver name: 'import dialog') QObject::connect: No such slot subversionPart::slotActionAdd() QObject::connect: (sender name: 'subversion_add') QObject::connect: (receiver name: 'Subversion') QObject::connect: No such slot subversionPart::slotActionRemove() QObject::connect: (sender name: 'subversion_remove') QObject::connect: (receiver name: 'Subversion') QObject::connect: No such slot subversionPart::slotActionAddToIgnoreList() QObject::connect: (sender name: 'subversion_ignore') QObject::connect: (receiver name: 'Subversion') QObject::connect: No such slot subversionPart::slotActionRemoveFromIgnoreList() QObject::connect: (sender name: 'subversion_donot_ignore') QObject::connect: (receiver name: 'Subversion') QObject::connect: No such slot subversionPart::slotStopButtonClicked(KDevPlugin*) QObject::connect: (sender name: 'unnamed') QObject::connect: (receiver name: 'Subversion') ASSERT: "part && parent" in partwidget.cpp (41) KCrash: Application 'kdevelop' crashing... The assert line is common with other crashes and happened on all the installs I tested on. In kdev 3.1.1, the application would keep running. In kdev 041101, it stops immediately.
The problem is the cpp parser, which doesn't manage to understand gdb-6.2/include/opcode/i386.h and balloons. The assert is unrelated, and harmless (!)
Which version did you test ? I assume you are referring to importing gdb-6.2 as a custom makefile project. How hard will this be to fix ? Do you want my help ?
BTW: Thanks for looking into the issue !
We always want help. :) The problem here (I'm guessing, haven't looked at the code yet) is that this is generic code that is incorrect in a specific case. This could prove to be very hard to fix.
I'm pretty sure this is the same problem as bug #97492 and that bug has a relevant backtrace, so.. *** This bug has been marked as a duplicate of 97492 ***
Moving all the bugs from the CPP Parser. It was not well defined the difference between it and C++ Language Support and people kept reporting in both places indistinctively