Version: 3.9.95-1 (using KDE 4.3.0) OS: Linux Installed from: Debian testing/unstable Packages When loading a project in my case id3lib-devel the background parser crashes with the following output Object::disconnect: Unexpected null parameter QObject: Cannot create children for a parent that is in a different thread. (Parent is Cpp::CodeCompletionModel(0x9288fc8), parent's thread is QThread(0x85c6d18), current thread is QThread(0x8edcc70) QObject: Cannot create children for a parent that is in a different thread. (Parent is Cpp::MissingIncludeCompletionModel(0x9283c20), parent's thread is QThread(0x85c6d18), current thread is QThread(0xade05560) kdevelop: Fatal IO error: client killed FunctionDeclarationData::m_defaultParameters There were items left on destruction: 236 FunctionTypeData::m_arguments There were items left on destruction: 16 ClassFunctionDeclarationData::m_defaultParameters There were items left on destruction: 663 ClassDeclarationData::baseClasses There were items left on destruction: 74 SpecialTemplateDeclarationData::m_specializations There were items left on destruction: 162 DUContextData::m_localDeclarations There were items left on destruction: 1014 DUContextData::m_childContexts There were items left on destruction: 1271 DUContextData::m_importers There were items left on destruction: 343 DUContextData::m_importedContexts There were items left on destruction: 368 pp_macro::formals There were items left on destruction: 793 pp_macro::definition There were items left on destruction: 5763 QSocketNotifier: Invalid socket 28 and type 'Read', disabling... KCrash: Application 'kdevelop' crashing...
You need to provide a backtrace from the crash, usually Dr. Konqi KDE's crash handler is being started when a crash occurs and allows you to generate one. Else run kdevelop in gdb and issue "thread apply all bt" when it crashes.
I istalled the kdevelop package from debian experimental so it is compiled without debug information. The KDE Crash Manager does therefore not provide any useful information. Nevertheless gdb printed some output maybe that is helpful. Otherwise I have to compile KDevelop on my own (which I do not know how at the moment) Here is the gdb output as requested: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xa958ab90 (LWP 22644)] 0xb5e73ef8 in KDevelop::FunctionDeclaration::toString() const () from /usr/lib/libkdevplatformlanguage.so.1 (gdb) thread apply all bt Thread 26 (Thread 0xa958ab90 (LWP 22644)): #0 0xb5e73ef8 in KDevelop::FunctionDeclaration::toString() const () from /usr/lib/libkdevplatformlanguage.so.1 #1 0xb5e9da3c in KDevelop::DumpChain::dump(KDevelop::DUContext*, int) () from /usr/lib/libkdevplatformlanguage.so.1 #2 0xb5e9f714 in KDevelop::DumpChain::dump(KDevelop::DUContext*, int) () from /usr/lib/libkdevplatformlanguage.so.1 #3 0xb5e9f3dc in KDevelop::DumpChain::dump(KDevelop::DUContext*, int) () from /usr/lib/libkdevplatformlanguage.so.1 #4 0xb5e9f3dc in KDevelop::DumpChain::dump(KDevelop::DUContext*, int) () from /usr/lib/libkdevplatformlanguage.so.1 #5 0xb5e9f3dc in KDevelop::DumpChain::dump(KDevelop::DUContext*, int) () from /usr/lib/libkdevplatformlanguage.so.1 #6 0xb5e9f3dc in KDevelop::DumpChain::dump(KDevelop::DUContext*, int) () from /usr/lib/libkdevplatformlanguage.so.1 #7 0xb5e9f3dc in KDevelop::DumpChain::dump(KDevelop::DUContext*, int) () from /usr/lib/libkdevplatformlanguage.so.1 #8 0xb5e9f3dc in KDevelop::DumpChain::dump(KDevelop::DUContext*, int) () from /usr/lib/libkdevplatformlanguage.so.1 #9 0xb5e9f3dc in KDevelop::DumpChain::dump(KDevelop::DUContext*, int) () from /usr/lib/libkdevplatformlanguage.so.1 #10 0xabfe4604 in ContextBuilder::buildContexts(KSharedPtr<Cpp::EnvironmentFile>, AST*, QList<LineContextPair>*, KDevelop::ReferencedTopDUContext const&, bool) () from /usr/lib/libkdev4cppduchain.so.3.9.94 #11 0xabff3081 in DeclarationBuilder::buildDeclarations(KSharedPtr<Cpp::EnvironmentFile>, AST*, QList<LineContextPair>*, KDevelop::ReferencedTopDUContext const&, bool) () from /usr/lib/libkdev4cppduchain.so.3.9.94 #12 0xac0e0950 in ?? () from /usr/lib/kde4/kdevcpplanguagesupport.so #13 0xac0d9b2d in ?? () from /usr/lib/kde4/kdevcpplanguagesupport.so #14 0xac0e7cf7 in ?? () from /usr/lib/kde4/kdevcpplanguagesupport.so #15 0xad31dd47 in rpp::pp::handle_include(bool, rpp::Stream&, rpp::Stream&) () from /usr/lib/libkdev4cpprpp.so.3.9.94 #16 0xad31e89b in rpp::pp::handle_directive(unsigned int, rpp::Stream&, rpp::Stream&) () from /usr/lib/libkdev4cpprpp.so.3.9.94 #17 0xad31ed42 in rpp::pp::operator()(rpp::Stream&, rpp::Stream&) () from /usr/lib/libkdev4cpprpp.so.3.9.94 #18 0xad31f188 in rpp::pp::processFileInternal(QString const&, QByteArray const&, QVector<unsigned int>&) () from /usr/lib/libkdev4cpprpp.so.3.9.94 #19 0xad31f225 in rpp::pp::processFile(QString const&, QByteArray const&) () from /usr/lib/libkdev4cpprpp.so.3.9.94 #20 0xac0ea90f in ?? () from /usr/lib/kde4/kdevcpplanguagesupport.so #21 0xb537d4f4 in ?? () from /usr/lib/libthreadweaver.so.4 #22 0xb537d871 in ThreadWeaver::Job::execute(ThreadWeaver::Thread*) () from /usr/lib/libthreadweaver.so.4 #23 0xb537f1f3 in ?? () from /usr/lib/libthreadweaver.so.4 #24 0xb537fb81 in ThreadWeaver::JobCollection::execute(ThreadWeaver::Thread*) () from /usr/lib/libthreadweaver.so.4 #25 0xb537c48a in ?? () from /usr/lib/libthreadweaver.so.4 #26 0xb537cafb in ThreadWeaver::Thread::run() () from /usr/lib/libthreadweaver.so.4 #27 0xb76ef582 in ?? () from /usr/lib/libQtCore.so.4 #28 0xb57204b5 in start_thread () from /lib/i686/cmov/libpthread.so.0 #29 0xb6b6fa5e in clone () from /lib/i686/cmov/libc.so.6 Thread 25 (Thread 0xa9d8bb90 (LWP 22643)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb5723f65 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb6b7e85d in pthread_cond_wait () from /lib/i686/cmov/libc.so.6 #3 0xb76f0562 in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4 #4 0xb537b648 in ?? () from /usr/lib/libthreadweaver.so.4 #5 0xb537e3ac in ?? () from /usr/lib/libthreadweaver.so.4 ---Type <return> to continue, or q <return> to quit--- #6 0xb537a23b in ?? () from /usr/lib/libthreadweaver.so.4 #7 0xb537e4a2 in ?? () from /usr/lib/libthreadweaver.so.4 #8 0xb537bbd3 in ?? () from /usr/lib/libthreadweaver.so.4 #9 0xb537c4be in ?? () from /usr/lib/libthreadweaver.so.4 #10 0xb537cafb in ThreadWeaver::Thread::run() () from /usr/lib/libthreadweaver.so.4 #11 0xb76ef582 in ?? () from /usr/lib/libQtCore.so.4 #12 0xb57204b5 in start_thread () from /lib/i686/cmov/libpthread.so.0 #13 0xb6b6fa5e in clone () from /lib/i686/cmov/libc.so.6 Thread 24 (Thread 0xaa78db90 (LWP 22642)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb5724292 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb6b7e8b4 in pthread_cond_timedwait () from /lib/i686/cmov/libc.so.6 #3 0xb76eef8e in ?? () from /usr/lib/libQtCore.so.4 #4 0xb76ef0bb in QThread::msleep(unsigned long) () from /usr/lib/libQtCore.so.4 #5 0xac0cb39b in ?? () from /usr/lib/kde4/kdevcpplanguagesupport.so #6 0xb76ef582 in ?? () from /usr/lib/libQtCore.so.4 #7 0xb57204b5 in start_thread () from /lib/i686/cmov/libpthread.so.0 #8 0xb6b6fa5e in clone () from /lib/i686/cmov/libc.so.6 Thread 23 (Thread 0xaaf8eb90 (LWP 22639)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb6b65467 in poll () from /lib/i686/cmov/libc.so.6 #2 0xb577cb3b in g_poll () from /usr/lib/libglib-2.0.so.0 #3 0xb576f795 in ?? () from /usr/lib/libglib-2.0.so.0 #4 0xb576fa48 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #5 0xb780b858 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #6 0xb77df01a in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #7 0xb77df462 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #8 0xb76ec2c9 in QThread::exec() () from /usr/lib/libQtCore.so.4 #9 0xb5f13ea0 in ?? () from /usr/lib/libkdevplatformlanguage.so.1 #10 0xb76ef582 in ?? () from /usr/lib/libQtCore.so.4 #11 0xb57204b5 in start_thread () from /lib/i686/cmov/libpthread.so.0 #12 0xb6b6fa5e in clone () from /lib/i686/cmov/libc.so.6 Thread 22 (Thread 0xab78fb90 (LWP 22638)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb6b65467 in poll () from /lib/i686/cmov/libc.so.6 #2 0xb577cb3b in g_poll () from /usr/lib/libglib-2.0.so.0 #3 0xb576f795 in ?? () from /usr/lib/libglib-2.0.so.0 #4 0xb576fa48 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #5 0xb780b858 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 ---Type <return> to continue, or q <return> to quit--- #6 0xb77df01a in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #7 0xb77df462 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #8 0xb76ec2c9 in QThread::exec() () from /usr/lib/libQtCore.so.4 #9 0xb5f13ea0 in ?? () from /usr/lib/libkdevplatformlanguage.so.1 #10 0xb76ef582 in ?? () from /usr/lib/libQtCore.so.4 #11 0xb57204b5 in start_thread () from /lib/i686/cmov/libpthread.so.0 #12 0xb6b6fa5e in clone () from /lib/i686/cmov/libc.so.6 Thread 21 (Thread 0xaddfdb90 (LWP 22637)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb5724292 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb6b7e8b4 in pthread_cond_timedwait () from /lib/i686/cmov/libc.so.6 #3 0xb76f053c in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4 #4 0xb76e5d3e in ?? () from /usr/lib/libQtCore.so.4 #5 0xb76ef582 in ?? () from /usr/lib/libQtCore.so.4 #6 0xb57204b5 in start_thread () from /lib/i686/cmov/libpthread.so.0 #7 0xb6b6fa5e in clone () from /lib/i686/cmov/libc.so.6 Thread 20 (Thread 0xaedffb90 (LWP 22636)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb5723f65 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb6b7e85d in pthread_cond_wait () from /lib/i686/cmov/libc.so.6 #3 0xb76f0562 in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4 #4 0xb537b648 in ?? () from /usr/lib/libthreadweaver.so.4 #5 0xb537e3ac in ?? () from /usr/lib/libthreadweaver.so.4 #6 0xb537a23b in ?? () from /usr/lib/libthreadweaver.so.4 #7 0xb537e4a2 in ?? () from /usr/lib/libthreadweaver.so.4 #8 0xb537bbd3 in ?? () from /usr/lib/libthreadweaver.so.4 #9 0xb537c4be in ?? () from /usr/lib/libthreadweaver.so.4 #10 0xb537cafb in ThreadWeaver::Thread::run() () from /usr/lib/libthreadweaver.so.4 #11 0xb76ef582 in ?? () from /usr/lib/libQtCore.so.4 #12 0xb57204b5 in start_thread () from /lib/i686/cmov/libpthread.so.0 #13 0xb6b6fa5e in clone () from /lib/i686/cmov/libc.so.6 Thread 19 (Thread 0xae5feb90 (LWP 22635)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb6b65467 in poll () from /lib/i686/cmov/libc.so.6 #2 0xb577cb3b in g_poll () from /usr/lib/libglib-2.0.so.0 #3 0xb576f795 in ?? () from /usr/lib/libglib-2.0.so.0 #4 0xb576fa48 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #5 0xb780b858 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #6 0xb77df01a in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 ---Type <return> to continue, or q <return> to quit--- #7 0xb77df462 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #8 0xb76ec2c9 in QThread::exec() () from /usr/lib/libQtCore.so.4 #9 0xb77c23fb in ?? () from /usr/lib/libQtCore.so.4 #10 0xb76ef582 in ?? () from /usr/lib/libQtCore.so.4 #11 0xb57204b5 in start_thread () from /lib/i686/cmov/libpthread.so.0 #12 0xb6b6fa5e in clone () from /lib/i686/cmov/libc.so.6 Thread 3 (Thread 0xaf75eb90 (LWP 22614)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb6b67fe1 in select () from /lib/i686/cmov/libc.so.6 #2 0xb77bec80 in ?? () from /usr/lib/libQtCore.so.4 #3 0xb76ef582 in ?? () from /usr/lib/libQtCore.so.4 #4 0xb57204b5 in start_thread () from /lib/i686/cmov/libpthread.so.0 #5 0xb6b6fa5e in clone () from /lib/i686/cmov/libc.so.6 Thread 2 (Thread 0xb1c10b90 (LWP 22613)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb5724292 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb6b7e8b4 in pthread_cond_timedwait () from /lib/i686/cmov/libc.so.6 #3 0xb76f053c in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4 #4 0xb5e11f65 in ?? () from /usr/lib/libkdevplatformlanguage.so.1 #5 0xb76ef582 in ?? () from /usr/lib/libQtCore.so.4 #6 0xb57204b5 in start_thread () from /lib/i686/cmov/libpthread.so.0 #7 0xb6b6fa5e in clone () from /lib/i686/cmov/libc.so.6 Thread 1 (Thread 0xb50f0700 (LWP 22610)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb6b65467 in poll () from /lib/i686/cmov/libc.so.6 #2 0xb577cb3b in g_poll () from /usr/lib/libglib-2.0.so.0 #3 0xb576f795 in ?? () from /usr/lib/libglib-2.0.so.0 #4 0xb576fa48 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #5 0xb780b858 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #6 0xb6ebffd5 in ?? () from /usr/lib/libQtGui.so.4 #7 0xb77df01a in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #8 0xb77df462 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #9 0xb77e18b9 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #10 0xb6e20697 in QApplication::exec() () from /usr/lib/libQtGui.so.4 #11 0x0804f13b in _start () (gdb)
Created attachment 36625 [details] Crash backtrace provided by KDE Crash Manager after installing kdevplatform-dbg I found out that after installing kdevplatform-dbg from debian experimental kdevelop and the crash manager can provide useful information. I attached the info as file and like to reopen the bug again.
Trying to reopen the bug since backtrace is provided now. If anything else is needed or even if I can help please contact me.
Can you please also install kdevelop-dbg? Additionally, please run kdebugdialog and activate the area 9007. Then reproduce the crash and provide the complete output from KDevelop. Hmm, looking at the output you posted already, did you eventually open a project and then close kdevelop while it was still parsing the files? I can see various "items left on destruction" messages there that hint towards kdevelop being shut down.
There is no package kdevelop-dbg in debian. Which server do I have to add or where can I get it from? kdebugdialog is working and 9007 set now. What I did is opening Kdevelop then going to recent projects and trying to open it. Then kdevelop directly crashes when 3% of the background parsing is done. I will try to get the package. Additionally I am adding the commands to get the non-working software package. cvs -d:pserver:anonymous@id3lib.cvs.sourceforge.net:/cvsroot/id3lib login cvs -z3 -d:pserver:anonymous@id3lib.cvs.sourceforge.net:/cvsroot/id3lib co -P id3lib-devel I then just created a new project by importing the makefile and (calling ./configure before) and then started parsing.
(In reply to comment #6) > There is no package kdevelop-dbg in debian. Which server do I have to add or > where can I get it from? Ask the debian packagers. They need to create one for useful backtraces. > kdebugdialog is working and 9007 set now. Can you please post the output you get in the terminal from which you start KDevelop. Andreas
Created attachment 36639 [details] Console output of Kdevelop with kdebugdialog activated 9007 This is the console output during kdevelop startup and loading of the project id3lib-devel.
Created attachment 36653 [details] gdb output of self compiled kdevelop with debug option enabled This gdb output is generated from a self compiled kdevelop with debug option enabled. It is part of the latest svn files. Does that help?
Adding the crash output of gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xaaa57b90 (LWP 13613)] 0xb5c68ede in KDevelop::FunctionDeclaration::toString (this=0xad39d0d0) at /home/nagilo/src/kdevplatform/language/duchain/functiondeclaration.cpp:79 79 return QString("%1 %2 %3").arg(function->partToString( FunctionType::SignatureReturn )).arg(identifier().toString()).arg(function->partToString( FunctionType::SignatureArguments ));
(In reply to comment #9) > Created an attachment (id=36653) [details] > gdb output of self compiled kdevelop with debug option enabled > > This gdb output is generated from a self compiled kdevelop with debug option > enabled. It is part of the latest svn files. Does that help? That mixes the package-plugins/libs with the self-compiled ones, this can produce various problems. If you want to create a backtrace with a self-compiled version then please remove all kdevelop and kdevplatform packages and build both from svn.
Hi, I really want to be polite and help you to find the bug since it is your project. If you have a look at the gdb output (which you certainly did) you see that both kdevplatform and kdevelop is compiled from source. Example line #9 0xb5d0aef0 in KDevelop::CompletionWorkerThread::run (this=0x88abdf8) at /home/nagilo/src/kdevplatform/language/codecompletion/codecompletionmodel.cpp:82 Even ldd reports correct linkage to the self made libs nagilo@mac:~/kdevelop4/bin$ ldd kdevelop linux-gate.so.1 => (0xb7f4c000) libkdecore.so.5 => /usr/lib/libkdecore.so.5 (0xb7cf0000) libkdevplatforminterfaces.so.1 => /home/nagilo/kdevelop4/lib/libkdevplatforminterfaces.so.1 (0xb7ccc000) libkdevplatformshell.so.1 => /home/nagilo/kdevelop4/lib/libkdevplatformshell.so.1 (0xb7bdd000) libkio.so.5 => /usr/lib/libkio.so.5 (0xb7961000) libkutils.so.4 => /usr/lib/libkutils.so.4 (0xb7919000) libkparts.so.4 => /usr/lib/libkparts.so.4 (0xb78de000) libknotifyconfig.so.4 => /usr/lib/libknotifyconfig.so.4 (0xb78ce000) libktexteditor.so.4 => /usr/lib/libktexteditor.so.4 (0xb789f000) libthreadweaver.so.4 => /usr/lib/libthreadweaver.so.4 (0xb788d000) libQtDesigner.so.4 => /usr/lib/libQtDesigner.so.4 (0xb7467000) libQtNetwork.so.4 => /usr/lib/libQtNetwork.so.4 (0xb734f000) libQtXml.so.4 => /usr/lib/libQtXml.so.4 (0xb730b000) libkdeui.so.5 => /usr/lib/libkdeui.so.5 (0xb6f82000) libQtDBus.so.4 => /usr/lib/libQtDBus.so.4 (0xb6f0e000) libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0xb6cd2000) libQtSvg.so.4 => /usr/lib/libQtSvg.so.4 (0xb6c7f000) libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0xb62c4000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb61d4000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb61ad000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6182000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6023000) libz.so.1 => /usr/lib/libz.so.1 (0xb600e000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb5ffe000) libkrosscore.so.4 => /usr/lib/libkrosscore.so.4 (0xb5fe1000) libQtScript.so.4 => /usr/lib/libQtScript.so.4 (0xb5eca000) libkde3support.so.4 => /usr/lib/libkde3support.so.4 (0xb5de7000) libkfile.so.4 => /usr/lib/libkfile.so.4 (0xb5d58000) libkdevplatformproject.so.1 => /home/nagilo/kdevelop4/lib/libkdevplatformproject.so.1 (0xb5d45000) libkdevplatformvcs.so.1 => /home/nagilo/kdevelop4/lib/libkdevplatformvcs.so.1 (0xb5cfc000) libkdevplatformlanguage.so.1 => /home/nagilo/kdevelop4/lib/libkdevplatformlanguage.so.1 (0xb5ad2000) libsublime.so.1 => /home/nagilo/kdevelop4/lib/libsublime.so.1 (0xb5a82000) libkdevplatformutil.so.1 => /home/nagilo/kdevelop4/lib/libkdevplatformutil.so.1 (0xb5a6b000) libkdevplatformoutputview.so.1 => /home/nagilo/kdevelop4/lib/libkdevplatformoutputview.so.1 (0xb5a65000) libkdevplatformdebugger.so.1 => /home/nagilo/kdevelop4/lib/libkdevplatformdebugger.so.1 (0xb5a2e000) libQt3Support.so.4 => /usr/lib/libQt3Support.so.4 (0xb5736000) libstreamanalyzer.so.0 => /usr/lib/libstreamanalyzer.so.0 (0xb56c8000) libsolid.so.4 => /usr/lib/libsolid.so.4 (0xb5657000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb553b000) libfam.so.0 => /usr/lib/libfam.so.0 (0xb5532000) libacl.so.1 => /lib/libacl.so.1 (0xb552a000) libattr.so.1 => /lib/libattr.so.1 (0xb5525000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb551c000) libphonon.so.4 => /usr/lib/libphonon.so.4 (0xb54cd000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb54b4000) libSM.so.6 => /usr/lib/libSM.so.6 (0xb54ab000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb5493000) libXtst.so.6 => /usr/lib/libXtst.so.6 (0xb548e000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb5485000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb5480000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb547a000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb5471000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb53bc000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb53b8000) libaudio.so.2 => /usr/lib/libaudio.so.2 (0xb53a2000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb537d000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb5306000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb52c9000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb529e000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb5290000) /lib/ld-linux.so.2 (0xb7f4d000) libkpty.so.4 => /usr/lib/libkpty.so.4 (0xb5287000) libQtSql.so.4 => /usr/lib/libQtSql.so.4 (0xb524b000) libstreams.so.0 => /usr/lib/libstreams.so.0 (0xb5210000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb50d9000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb50c0000) libuuid.so.1 => /lib/libuuid.so.1 (0xb50bc000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb508b000) libXt.so.6 => /usr/lib/libXt.so.6 (0xb503a000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb5037000) libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0xb5011000) libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb500d000) libutempter.so.0 => /usr/lib/libutempter.so.0 (0xb500b000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb5006000) Nevertheless the main reason that I do not have linkage problems is that I get EXACTLY the same behvior with the debian packages and the self compiled ones. I really would like to help but up to now I spent much time to generate the backtrace and all you answer is that it is not useful. I also try to develop open source software and I know that it is sometimes frustrating and you do not have enough time but either you are really intersted to help me (what I really would appreciate) or you just mark the bug as IGNORE and leave it (which I can also understand). Sorry for these words but I spend several hours now. Yours Norbert
(In reply to comment #12) > I really want to be polite and help you to find the bug since it is your > project. > > If you have a look at the gdb output (which you certainly did) you see that > both kdevplatform and kdevelop is compiled from source. Example line You may well have built both from sources, but the running instance uses a mix of your self-compiled and the package versions. This can be dangerous due to C++ bc rules. The proof for that is this excerpt from your last backtrace: #8 0xb5c94a62 in KDevelop::DumpChain::dump (this=0xaaa54ed4, context=0xad7deb58, allowedDepth=0) at /home/nagilo/src/kdevplatform/language/duchain/dumpchain.cpp:116 #9 0xac620604 in ContextBuilder::buildContexts(KSharedPtr<Cpp::EnvironmentFile>, AST*, QList<LineContextPair>*, KDevelop::ReferencedTopDUContext const&, bool) () from /usr/lib/libkdev4cppduchain.so.3.9.94 As you can see, dumpchain.cpp is from your self-compiled installation, but the C++ duchain library is taken from /usr/lib. > Even ldd reports correct linkage to the self made libs The binary "kdevelop" is just a very thin thing that loads the rest. In particular which language plugin is loaded depends on other things than the linker path. > Nevertheless the main reason that I do not have linkage problems is that I get > EXACTLY the same behvior with the debian packages and the self compiled ones. Its not about linkage problems (well maybe), the point is that the backtrace misses some information and thats because you're loading a plugin from /usr/lib/kde4 instead of from your self-compiled version. The easiest way to fix that is removing the packages, hence I suggested that. > I really would like to help but up to now I spent much time to generate the > backtrace and all you answer is that it is not useful. I didn't say its not useful, I'm just trying to get as much information as I can from you to get a complete picture. In particular from where the chain-dumping is initiated. > I also try to develop open source software and I know that it is sometimes > frustrating and you do not have enough time but either you are really intersted > to help me (what I really would appreciate) or you just mark the bug as IGNORE > and leave it (which I can also understand). If it would be any of that, I wouldn't have even bothered asking the first question. BTW, I just thought of something that might help: try deleting $HOME/.kdevduchain and then start importing the project again.
First of all - sorry I did not see the whole story - in fact you are right ... so back to the report First I deleted $HOME/.kdevduchain reloaded again the project - but same issue. I found out that I did not read the manual to compile kdevelop to the end so I executed export KDEDIRS=$HOME/kdevelop4:/usr kbuildsycoca4 Which in fact forces kdevelop to use the correct plugin dir. Then I rerun gdb -- but see the appended file... It is interesting that libkdev4cppduchain is not mentioned at all in the new gdb output but maybe you know why. In fact the line where the crash occurs (src/kdevplatform/language/duchain/functiondeclaration.cpp:79) is the same.
Created attachment 36671 [details] gdb output of self compiled kdevelop and correct plugin path (all debian packages removed) This is the latest gdb output where all debian kdev* packages are removed... If anything else is needed (for example the parsed source code) ...
New insights: The crash is only depending on id3lib_bitset (which is added for NetBSD and MacOS). If I make that file empty parsing is fine.
Thanks a lot, kdev4cppduchain is still in the backtrace, its just that now we get to actually see which of its source files (and more importantly which line in that file) tries to dump the chain. In addition its good that this is well-reproduceable and that you could narrow it down to only a single file. That really helps a lot when debugging this.
Ok I exactly located the point where parsing failed - looking at the definition inside id3lib_bitset template<bool __dummy> unsigned char _First_one<__dummy>::_S_first_one[] = { 0, /* 0 */ 0, /* 1 */ 1, /* 2 */ 0, /* 3 */ 2, /* 4 */ <snip> 1, /* 250 */ 0, /* 251 */ 2, /* 252 */ 0, /* 253 */ 1, /* 254 */ 0, /* 255 */ }; // end _First_one There is an additional comma at the end of the array in front of the comment /*255*/ If I remove that comma and change it to template<bool __dummy> unsigned char _First_one<__dummy>::_S_first_one[] = { 0, /* 0 */ 0, /* 1 */ 1, /* 2 */ 0, /* 3 */ 2, /* 4 */ <snip> 1, /* 250 */ 0, /* 251 */ 2, /* 252 */ 0, /* 253 */ 1, /* 254 */ 0 /* 255 */ }; // end _First_one parsing is just fine.
thanks for your continued work, that should give David all the needed information to fix this once he gets around to it.
OK thanks so far happy debugging
Has anyone been able to reproduce this? I've downloaded id3lib and made a project out of it, and the DUChain seems to have been processed without issue. The offending code is still there in id3lib_bitset...
I couldn't reproduce the problem using the given code-snippet, and since Olivier.jg also couldn't reproduce it, I close this bug as fixed for now. If you can still reproduce the problem, reopen the bug-report, and please try providing a code-snippet that makes kdevelop crash.
Hello, I still can reproduce the bug. I committed the above mentioned simple solution to the id3lib_bitset in revision 1.2. If you go back to 1.1 you still get the problem. (KDevelop 3.9.95) These steps are required: cvs -z3 -d:pserver:anonymous@id3lib.cvs.sourceforge.net:/cvsroot/id3lib co -P id3lib-devel cd id3lib-devel/include/id3/ cvs update -r 1.1 id3lib_bitset cd- ./configure --> Import Kdevelop project Thanks for your excellent work.
Here is the cvs diff of id3lib_bitset http://id3lib.cvs.sourceforge.net/viewvc/id3lib/id3lib-devel/include/id3/id3lib_bitset?r1=1.1&r2=1.2
Well, so it might be that this has been fixed after KDevelop Beta5, please re-open if you can reproduce with current trunk (or the Beta6 that'll be released next weekend)
*** Bug 213829 has been marked as a duplicate of this bug. ***
please, note my duplicate. Very easy to reproduce, just create a cpp file with the following content: typedef void (*foo)(); template If anybody with beta6 can try this that would be great.
@Giuseppe: Tested, it did not crash.
Tested today, it work fine! Thank you very much.