Bug 297133 - c++: searching for declaration sometimes requires writelock when template declaration is instantiated
Summary: c++: searching for declaration sometimes requires writelock when template dec...
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: general (show other bugs)
Version: 4.3.60
Platform: Ubuntu Linux
: NOR crash
Target Milestone: 4.3.0
Assignee: kdevelop-bugs-null
URL:
Keywords:
: 300440 306394 307352 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-03-30 19:18 UTC by Leandro Santiago da Silva
Modified: 2012-11-11 22:08 UTC (History)
6 users (show)

See Also:
Latest Commit: http://commits.kde.org/kdevelop/e112a01c5c5b3562320afed848725f91e920a3c7
Version Fixed In:
Sentry Crash Report:

Attachments
crash backtrace from gdb (84.34 KB, application/octet-stream)
2012-06-11 02:21 UTC, Leandro Santiago da Silva 		Details
test case (44.78 KB, application/x-gzip)
2012-06-16 10:32 UTC, Adam Wood 		Details
New crash information added by DrKonqi (19.74 KB, text/plain)
2012-06-20 20:34 UTC, Leandro Santiago da Silva 		Details
KDevelop console output. (12.71 KB, text/plain)
2012-06-20 20:37 UTC, Leandro Santiago da Silva 		Details
Kdevplatform patch (2.65 KB, patch)
2012-07-01 09:00 UTC, Adam Wood 		Details
Kdevelop patch (608 bytes, patch)
2012-07-01 09:00 UTC, Adam Wood 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Leandro Santiago da Silva 2012-03-30 19:18:20 UTC 
Application: kdevelop (4.3.60)
KDE Platform Version: 4.8.1 (4.8.1)
Qt Version: 4.8.0
Operating System: Linux 3.3.0-030300-generic x86_64
Distribution: Ubuntu 11.10

-- Information about the crash:
- What I was doing when the application crashed:

I rebuilt kdevelop (and kdevplatform, etc.) from the master branch and now it crashes everytime.  I have three project opened (llvm, kdevelop and another private) and it always crashes in the same point.

Before reinstalling kdevelop, I removed completely it and its components (plugins, etc.), so I think it's not a problem with old libraries. I also removed the .kdevduchain dir.

I tried this process twice or more times.

- Unusual behavior I noticed:
KDevelop crashes everytime, after some minutes analysing the projects.

The crash can be reproduced every time.

-- Backtrace:
Application: KDevelop (kdevelop), signal: Aborted
pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
	in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S
[Current thread is 1 (Thread 0x7f486c1647a0 (LWP 12157))]

Thread 12 (Thread 0x7f484304f700 (LWP 12159)):
#0  0x00007f48692d5473 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007f48641bdf68 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f48641be429 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f486a71abbf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4  0x00007f486a6ea402 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5  0x00007f486a6ea657 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#6  0x00007f486a5ea067 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#7  0x00007f486a5ed08b in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#8  0x00007f4868652efc in start_thread (arg=0x7f484304f700) at pthread_create.c:304
#9  0x00007f48692e159d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()

Thread 11 (Thread 0x7f4841da9700 (LWP 12160)):
#0  0x00007f48692da613 in select () at ../sysdeps/unix/syscall-template.S:82
#1  0x00007f486a6c8621 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#2  0x00007f486a5ed08b in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#3  0x00007f4868652efc in start_thread (arg=0x7f4841da9700) at pthread_create.c:304
#4  0x00007f48692e159d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5  0x0000000000000000 in ?? ()

Thread 10 (Thread 0x7f483cd55700 (LWP 12162)):
#0  0x00007f48692d5473 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007f48641bdf68 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f48641be429 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f486a71abbf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4  0x00007f486a6ea402 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5  0x00007f486a6ea657 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#6  0x00007f486a5ea067 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#7  0x00007f486a6ca17f in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#8  0x00007f486a5ed08b in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#9  0x00007f4868652efc in start_thread (arg=0x7f483cd55700) at pthread_create.c:304
#10 0x00007f48692e159d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()

Thread 9 (Thread 0x7f483c502700 (LWP 12180)):
#0  0x00007f48692d5473 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007f48641bdf68 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f48641be429 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f486a71abbf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4  0x00007f486a6ea402 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5  0x00007f486a6ea657 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#6  0x00007f486a5ea067 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#7  0x00007f486a6ca17f in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#8  0x00007f486a5ed08b in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#9  0x00007f4868652efc in start_thread (arg=0x7f483c502700) at pthread_create.c:304
#10 0x00007f48692e159d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()

Thread 8 (Thread 0x7f483a877700 (LWP 12305)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007f4861515c2c in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4
#2  0x00007f4861515d59 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4
#3  0x00007f4868652efc in start_thread (arg=0x7f483a877700) at pthread_create.c:304
#4  0x00007f48692e159d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5  0x0000000000000000 in ?? ()

Thread 7 (Thread 0x7f483b078700 (LWP 12339)):
#0  0x00007f48692d5473 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007f48641bdf68 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f48641be429 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f486a71ac26 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4  0x00007f486a6ea402 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5  0x00007f486a6ea657 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#6  0x00007f486a5ea067 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#7  0x00007f486a5ed08b in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#8  0x00007f4868652efc in start_thread (arg=0x7f483b078700) at pthread_create.c:304
#9  0x00007f48692e159d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()

Thread 6 (Thread 0x7f47f2ffd700 (LWP 12544)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007f485285a042 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#2  0x00007f485285a079 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#3  0x00007f4868652efc in start_thread (arg=0x7f47f2ffd700) at pthread_create.c:304
#4  0x00007f48692e159d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5  0x0000000000000000 in ?? ()

Thread 5 (Thread 0x7f47f3fff700 (LWP 9890)):
[KCrash Handler]
#6  0x00007f48692343a5 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#7  0x00007f4869237b0b in __GI_abort () at abort.c:92
#8  0x00007f486a5e25cb in qt_message_output(QtMsgType, char const*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#9  0x00007f486a5e297f in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#10 0x00007f486a5e2b24 in qFatal(char const*, ...) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#11 0x00007f48380ed6f6 in Cpp::TemplateDeclaration::deleteAllInstantiations (this=0x7f47e9a24c80) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/templatedeclaration.cpp:712
#12 0x00007f48380edb1b in Cpp::TemplateDeclaration::~TemplateDeclaration (this=0x7f47e9a24c80, __in_chrg=<optimized out>) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/templatedeclaration.cpp:316
#13 0x00007f48380bac9a in Cpp::SpecialTemplateDeclaration<TemplateParameterDeclaration>::~SpecialTemplateDeclaration (this=0x7f47e9a24c50, __in_chrg=<optimized out>) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/templatedeclaration.h:247
#14 0x00007f48380bacc9 in Cpp::SpecialTemplateDeclaration<TemplateParameterDeclaration>::~SpecialTemplateDeclaration (this=0x7f47e9a24c50, __in_chrg=<optimized out>) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/templatedeclaration.h:247
#15 0x00007f4866973b19 in KDevelop::DUContext::deleteLocalDeclarations (this=<optimized out>) at /home/tenchi/projects/kdevelop/kdevplatform/language/duchain/ducontext.cpp:1080
#16 0x00007f4866975d60 in KDevelop::DUContext::~DUContext (this=0x7f47eb55cd10, __in_chrg=<optimized out>) at /home/tenchi/projects/kdevelop/kdevplatform/language/duchain/ducontext.cpp:518
#17 0x00007f4838090128 in Cpp::CppDUContext<KDevelop::DUContext>::~CppDUContext (this=0x7f47eb55cd10, __in_chrg=<optimized out>) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/cppducontext.h:713
#18 0x00007f4838090139 in Cpp::CppDUContext<KDevelop::DUContext>::~CppDUContext (this=0x7f47eb55cd10, __in_chrg=<optimized out>) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/cppducontext.h:713
#19 0x00007f48380ef913 in Cpp::TemplateDeclaration::instantiate (this=0x7f47ead7e730, _templateArguments=..., source=<optimized out>, forceLocal=<optimized out>) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/templatedeclaration.cpp:901
#20 0x00007f48380e44ed in Cpp::FindDeclaration::instantiateDeclaration (this=0x7f47f3ffc540, decl=<optimized out>, templateArguments=<optimized out>) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/cppducontext.cpp:125
#21 0x00007f48380e5672 in Cpp::FindDeclaration::closeIdentifier (this=0x7f47f3ffc540, isFinalIdentifier=true) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/cppducontext.cpp:273
#22 0x00007f4838095552 in Cpp::CppDUContext<KDevelop::TopDUContext>::findDeclarationsInternal (this=0x7f47eb829eb0, identifier=..., position=<optimized out>, dataType=<optimized out>, ret=..., source=0x7f47eb829eb0, basicFlags=...) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/cppducontext.h:363
#23 0x00007f4838095b10 in Cpp::CppDUContext<KDevelop::TopDUContext>::findDeclarationsInternal (this=0x7f47eb829eb0, identifiers=..., position=..., dataType=..., ret=..., source=0x7f47eb829eb0, basicFlags=..., depth=0) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/cppducontext.h:286
#24 0x00007f4866971145 in KDevelop::DUContext::findDeclarations (this=0x7f47eb829eb0, identifier=<optimized out>, position=..., dataType=..., topContext=<optimized out>, flags=...) at /home/tenchi/projects/kdevelop/kdevplatform/language/duchain/ducontext.cpp:839
#25 0x00007f48380bea71 in TypeBuilder::openTypeFromName (this=0x7f47f3ffdcd0, name=0x7f47eb33c3d0, modifiers=0, needClass=false) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/typebuilder.cpp:497
#26 0x00007f48380bfe9a in TypeBuilder::visitSimpleTypeSpecifier (this=0x7f47f3ffdcd0, node=0x7f47eb33c400) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/typebuilder.cpp:401
#27 0x00007f48380be3b9 in TypeBuilder::visitSimpleDeclaration (this=0x7f47f3ffdcd0, node=0x7f47eb33c830) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/typebuilder.cpp:624
#28 0x00007f4838099b4d in DeclarationBuilder::visitSimpleDeclaration (this=0x7f47f3ffdcd0, node=0x7f47eb33c830) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/declarationbuilder.cpp:379
#29 0x00007f47f21d054d in visitNodes<DeclarationAST*> (v=0x7f47f3ffdd30, nodes=<optimized out>) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/parser/visitor.h:139
#30 0x00007f483808be58 in KDevelop::AbstractContextBuilder<AST, NameAST>::supportBuild (this=0x7f47f3ffdcd0, node=0x7f47eb32e980, context=0x7f47eb829eb0) at /usr/include/kdevplatform/language/duchain/builders/abstractcontextbuilder.h:133
#31 0x00007f483808a533 in ContextBuilder::buildContexts (this=0x7f47f3ffdcd0, file=..., node=0x7f47eb32e980, includes=<optimized out>, updateContext=<optimized out>, removeOldImports=false) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/contextbuilder.cpp:421
#32 0x00007f4838097763 in DeclarationBuilder::buildDeclarations (this=0x7f47f3ffdcd0, file=<optimized out>, node=0x7f47eb32e980, includes=<optimized out>, updateContext=<optimized out>, removeOldImports=false) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/declarationbuilder.cpp:94
#33 0x00007f47f244fd10 in CPPInternalParseJob::run (this=0x5f699a0) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppparsejob.cpp:639
#34 0x00007f4861efb491 in ?? () from /usr/lib/libthreadweaver.so.4
#35 0x00007f4861efb5bc in ThreadWeaver::Job::execute(ThreadWeaver::Thread*) () from /usr/lib/libthreadweaver.so.4
#36 0x00007f4861efc603 in ?? () from /usr/lib/libthreadweaver.so.4
#37 0x00007f4861efac9f in ?? () from /usr/lib/libthreadweaver.so.4
#38 0x00007f4861efad5b in ThreadWeaver::Thread::run() () from /usr/lib/libthreadweaver.so.4
#39 0x00007f486a5ed08b in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#40 0x00007f4868652efc in start_thread (arg=0x7f47f3fff700) at pthread_create.c:304
#41 0x00007f48692e159d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#42 0x0000000000000000 in ?? ()

Thread 4 (Thread 0x7f4838fd4700 (LWP 11327)):
#0  0x00007f48692d5473 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007f48641bdf68 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f48641be429 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f486a71abbf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4  0x00007f486a6ea402 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5  0x00007f486a6ea657 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#6  0x00007f486a5ea067 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#7  0x00007f486a5ed08b in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#8  0x00007f4868652efc in start_thread (arg=0x7f4838fd4700) at pthread_create.c:304
#9  0x00007f48692e159d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()

Thread 3 (Thread 0x7f47f21b3700 (LWP 11328)):
#0  0x00007f48692d5473 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007f48641bdf68 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f48641be429 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f486a71abbf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4  0x00007f486a6ea402 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5  0x00007f486a6ea657 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#6  0x00007f486a5ea067 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#7  0x00007f486a5ed08b in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#8  0x00007f4868652efc in start_thread (arg=0x7f47f21b3700) at pthread_create.c:304
#9  0x00007f48692e159d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7f47f19b2700 (LWP 11366)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007f486a5ed59b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#2  0x00007f4861ef9864 in ?? () from /usr/lib/libthreadweaver.so.4
#3  0x00007f4861efbe0b in ?? () from /usr/lib/libthreadweaver.so.4
#4  0x00007f4861efbe24 in ?? () from /usr/lib/libthreadweaver.so.4
#5  0x00007f4861efbe24 in ?? () from /usr/lib/libthreadweaver.so.4
#6  0x00007f4861efaccf in ?? () from /usr/lib/libthreadweaver.so.4
#7  0x00007f4861efad5b in ThreadWeaver::Thread::run() () from /usr/lib/libthreadweaver.so.4
#8  0x00007f486a5ed08b in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#9  0x00007f4868652efc in start_thread (arg=0x7f47f19b2700) at pthread_create.c:304
#10 0x00007f48692e159d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f486c1647a0 (LWP 12157)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007f486a5ed59b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#2  0x00007f486a5ecca8 in QThread::wait(unsigned long) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#3  0x00007f486a6c8120 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4  0x00007f4869239821 in __run_exit_handlers (status=1, listp=0x7f48695985a8, run_list_atexit=true) at exit.c:78
#5  0x00007f48692398a5 in __GI_exit (status=<optimized out>) at exit.c:100
#6  0x00007f4869adcce8 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#7  0x00007f486aef0c68 in KApplication::xioErrhandler(_XDisplay*) () from /usr/lib/libkdeui.so.5
#8  0x00007f486565211e in _XIOError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9  0x00007f486564f8fd in _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#10 0x00007f486564019f in XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#11 0x00007f4869b16127 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#12 0x00007f48641bcff2 in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007f48641bddfd in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007f48641be429 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007f486a71abbf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#16 0x00007f4869b1628e in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#17 0x00007f486a6ea402 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#18 0x00007f486a6ea657 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#19 0x00007f486a6ef6e7 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#20 0x000000000040a1d4 in main (argc=<optimized out>, argv=<optimized out>) at /home/tenchi/projects/kdevelop/kdevelop/app/main.cpp:479

Reported using DrKonqi
Comment 1 Milian Wolff 2012-04-09 21:13:54 UTC 
sigh this is because the duchain was not write locked :-S

david: searching for a declaration should only require the readlock, but in templatedeclaration::instantiate there is code that creates a temporary context and deletes it afterwards (delete newTemplateContext;) which can cause the above - any idea what to do here?

@leandro: do you have a reproducible test case for this?
Comment 2 Adam Wood 2012-06-09 15:04:47 UTC 
*** Bug 300440 has been marked as a duplicate of this bug. ***
Comment 3 Leandro Santiago da Silva 2012-06-11 02:21:04 UTC 
(In reply to comment #1)
> sigh this is because the duchain was not write locked :-S
> 
> david: searching for a declaration should only require the readlock, but in
> templatedeclaration::instantiate there is code that creates a temporary
> context and deletes it afterwards (delete newTemplateContext;) which can
> cause the above - any idea what to do here?
> 
> @leandro: do you have a reproducible test case for this?

Millian, sorry for the delay (of some months!). O don't know if it will happen in another installation, but I tried and tried again with master branch versions of kdevelop and this bug still happens. The funniest part is it occours only when I have opened a copy of llvm source tree. The copy I'm using if from the LLVM official git mirror: http://llvm.org/git/llvm.git

Today I recompiled kdevelop and opened llvm and again after some minutes of project analysis, kdevelop crashed. I'm also sending the output of the backtrace I could get with gdb.
Comment 4 Leandro Santiago da Silva 2012-06-11 02:21:45 UTC 
Created attachment 71719 [details]
crash backtrace from gdb
Comment 5 Adam Wood 2012-06-16 10:32:10 UTC 
Created attachment 71868 [details]
test case

Attached test case.

I created a standard hello world cmake project.
I simply added #include <boost/proto/matches.hpp> and it crashed almost immediately.
Included in the gzipped test case is the full debug output in a txt file that clearly shows near the end that the boost include is responsible.

Any help tracking this down would be greatly appreciated as it's likely to mean I have to switch away from kdevelop very soon.  I'm happy to put in a good deal of effort myself to fix this but I don't know enough about the locking within duchain to get very far.
Comment 6 Adam Wood 2012-06-16 10:33:58 UTC 
I had intended to state that I'm using boost 1.49.0
Comment 7 Leandro Santiago da Silva 2012-06-20 20:34:51 UTC 
Created attachment 71999 [details]
New crash information added by DrKonqi

kdevelop (4.3.60) on KDE Platform 4.8.3 (4.8.3) using Qt 4.8.1

- What I was doing when the application crashed:
I imported the LLVM CMake project. Only it
- Unusual behavior I noticed:
KDevelop crashed.

To invalidate the hypotesis of a dirty installation, I reinstalled Kubuntu 12.04 in a clean partition and compiled KDevelop (and related libraries) from a clean source code tree. The probelm still happens.

-- Backtrace (Reduced):
#6  0x00007f189a87a445 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#7  0x00007f189a87dbab in __GI_abort () at abort.c:91
[...]
#11 0x00007f1806c6b366 in Cpp::TemplateDeclaration::deleteAllInstantiations (this=0x7f17f25bdb60) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/templatedeclaration.cpp:712
#12 0x00007f1806c6b78b in Cpp::TemplateDeclaration::~TemplateDeclaration (this=0x7f17f25bdb60, __in_chrg=<optimized out>) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/templatedeclaration.cpp:316
#13 0x00007f1806c37b6a in Cpp::SpecialTemplateDeclaration<TemplateParameterDeclaration>::~SpecialTemplateDeclaration (this=0x7f17f25bdb30, __in_chrg=<optimized out>) at /home/tenchi/projects/kdevelop/kdevelop/languages/cpp/cppduchain/templatedeclaration.h:247
Comment 8 Leandro Santiago da Silva 2012-06-20 20:36:11 UTC 
I don't know if it will happen, but I'm also sending console output of kdevelop in moment of crashing.
Comment 9 Leandro Santiago da Silva 2012-06-20 20:37:07 UTC 
Created attachment 72000 [details]
KDevelop console output.
Comment 10 Adam Wood 2012-07-01 09:00:08 UTC 
Created attachment 72252 [details]
Kdevplatform patch

This may not be an ideal fix but it has certainly improved the stability of my build.  The patch is in two parts.  First a kdevplatform patch to store the temporary contexts required by template instantiations, along with appropriate clean up.  The second part is a small patch to kdevelop so that instead of deleting directly, the temporary context deletion is postponed.
Comment 11 Adam Wood 2012-07-01 09:00:31 UTC 
Created attachment 72253 [details]
Kdevelop patch
Comment 12 Leandro Santiago da Silva 2012-07-01 18:12:52 UTC 
Just an update:  One way to reproduce this bug is getting the llvm source code from git (http://llvm.org/git/llvm.git) and then putting clang (http://llvm.org/svn/llvm-project/cfe/trunk) source code in llvm/tools/ as described in clang page. This bug happens here only when I have clang as a llvm subproject. When I open only llvm without clang, kdevelop doesn't crash.
Comment 13 Milian Wolff 2012-10-05 18:59:28 UTC 
*** Bug 307352 has been marked as a duplicate of this bug. ***
Comment 14 Milian Wolff 2012-10-05 18:59:34 UTC 
*** Bug 306394 has been marked as a duplicate of this bug. ***
Comment 15 Milian Wolff 2012-10-06 17:36:59 UTC 
I think the issue is rather, that when one clones a declaration with an internal context, both the original and the clone reference the same context... Maybe it would be sufficient to also clone the internal context and ensure that it will not be "inDUChain()".

Here is a different patch that simply prevents the call to internalContext->setOwner for cloned declarations... Not really nice but seems to work. Of course, the correct way would be the above, this is just a proof-of-concept.

diff --git a/language/duchain/declaration.cpp b/language/duchain/declaration.cpp
index 6a8cdcc..e5f5df2 100644
--- a/language/duchain/declaration.cpp
+++ b/language/duchain/declaration.cpp
@@ -160,7 +160,7 @@ Declaration::~Declaration()
   TopDUContext* topContext = this->topContext();
 
   //Only perform the actions when the top-context isn't being deleted, or when it hasn't been stored to disk
-  if(persistentlyDestroying()) {
+  if(persistentlyDestroying() && !d_func()->m_wasCloned) {
     DUCHAIN_D_DYNAMIC(Declaration);
     // Inserted by the builder after construction has finished.
     if( d->m_internalContext.context() )
@@ -677,6 +677,7 @@ Declaration* Declaration::clonePrivate() const  {
 Declaration* Declaration::clone() const  {
   Declaration* ret = clonePrivate();
   ret->d_func_dynamic()->m_inSymbolTable = false;
+  ret->d_func_dynamic()->m_wasCloned = true;
   return ret;
 }
 
diff --git a/language/duchain/declarationdata.h b/language/duchain/declarationdata.h
index f484f9d..4616358 100644
--- a/language/duchain/declarationdata.h
+++ b/language/duchain/declarationdata.h
@@ -62,6 +62,7 @@ public:
   bool m_alwaysForceDirect : 1;
   bool m_isAutoDeclaration : 1;
   bool m_isExplicitlyDeleted : 1;
+  bool m_wasCloned : 1;
 };
 }
Comment 16 David Nolden 2012-10-07 11:52:45 UTC 
Actually, a global write lock should not be required to delete the temporary context, because it's not in the duchain, and thus it's not visible to other threads.

Can you check, whether simply removing the ENSURE_CHAIN_WRITE_LOCK would fix the issue?

The correct solution would be, to replace it with "if(dynamic_cast<Declaration*>(this)->inDUChain() { ENSURE_CHAIN_WRITE_LOCKED }". This is how the check is performed in KDevelop::DUContext and KDevelop::Declaration.
Comment 17 David Nolden 2012-10-07 13:18:39 UTC 
Since the code is called from within the destructor, dynamic_cast doesn't work. I guess we should simply remove this check.
Comment 18 Milian Wolff 2012-10-07 17:24:55 UTC 
for those interested in trying out a patch: https://git.reviewboard.kde.org/r/106757/
Comment 19 Milian Wolff 2012-10-08 09:41:42 UTC 
Git commit e112a01c5c5b3562320afed848725f91e920a3c7 by Milian Wolff.
Committed on 08/10/2012 at 11:39.
Pushed by mwolff into branch 'master'.

Make temporary DUContext for default template parameters obsolete.

Use a thread-local QMultiHash<IndexedQualifiedIdentifier, IndexedType> lookup table to
support default template parameters. This obsoletes the necessity of the temporary DUContext
which may introduce instabilities as described in bug 297133.

One big caveat was cloning template declarations which contain an internal context. This
resulted in both, the original and clone to reference the same internal context. Upon
destruction of the clone, the ownership of the internal context was tried to be changed.
 This can crash, as it could happen while only holding a read lock, yet the referenced internal
context is in the DUChain and thus must only be altered while holding a write lock.

This change also makes it possible to remove the code surrounding Declaration::clone and
Declaration::clonePrivate, as this was the only places which actually used it.
Considering the major pitfalls and caveats of this API, I say this is a very good thing.

Furthermore, while introducing the thread-local data, I fixed the two safety recursion counters:
Previously they where shared between threads which does not make any sense when we want to count
the recursion depth that is thread-specific.

REVIEW: 106757

M  +137  -84   languages/cpp/cppduchain/templatedeclaration.cpp
M  +5    -0    languages/cpp/cppduchain/templateparameterdeclaration.cpp
M  +5    -0    languages/cpp/cppduchain/templateparameterdeclaration.h

http://commits.kde.org/kdevelop/e112a01c5c5b3562320afed848725f91e920a3c7
Comment 20 András Manţia 2012-10-09 10:15:32 UTC 
Thanks a lot, I can load again my project in KDevelop!
Comment 21 Daniel Scharrer 2012-11-11 22:08:24 UTC 
The above patch doesn't seem to have been included in 4.4.0 and 4.4.1 but seems to apply fine and fix the issue in those releases. If you do another 4.4.* release, can you please consider including commit e112a01c5c5b3562320afed848725f91e920a3c7? Without it KDevelop is so unstable for me it's basically useless.

Also, is there a better way to find out what realeases bug marked as FIXED is actually fixed in than cloning the whole git repo and grepping the logs?

Thanks.