I get a crash in the background parser when loading the coolfluid project. Tested with: https://github.com/coolfluid/coolfluid3/ The crash happens every time on OS X, using the latest git version compiled with KDE 4.9 from MacPorts. I can only reproduce the crash on OS X. Reproducible: Always Steps to Reproduce: Load the coolfluid project into kdevelop Actual Results: KDevelop crashes during the background parse.
Created attachment 75969 [details] backtrace
Forgot to add, the exact place where it always crashes is here: https://github.com/coolfluid/coolfluid3/blob/master/cf3/mesh/Region.hpp#L40-L41 I checked on linux, same git revision of kdevelop and same boost (1.52), and I can't reproduce it. On OS X it crashes every single time with as last output: kdevelop(4273)/kdevelop (cpp duchain) Cpp::TemplateDeclaration::instantiate: tried to recursively instantiate "class ComponentIterator" with "<cf3::mesh::Entities>" On Linux, this output is also present, but it doesn't crash, continuing instead with the statements: kdevelop(4273)/kdevelop (cpp support) Cpp::CppDUContext<Base>::setInstantiatedFrom: created orphaned instantiation for "boost::is_same< boost::use_default >" kdevelop(4273)/kdevelop (cpp support) Cpp::CppDUContext<Base>::setInstantiatedFrom: created orphaned instantiation for "is_same< boost::use_default >"
The backtrace is garbage, it does not contain any information - did you really wrote the "thread apply all bt" into a GDB console? More looks like a raw shell...
Created attachment 75973 [details] Correct back trace Sorry, looks like I managed to upload the wrong file!
backtrace supplied, changing bug status.
From your backtrace: "The program is running. Exit anyway? (y or n) error while killing target (killing anyway): assertion failure on line 219 of "/SourceCache/gdb/gdb-1822/src/gdb/macosx/macosx-nat-inferior-util.c" in function "kern_return_t macosx_inferior_suspend_mach(macosx_inferior_status *)": macosx_task_valid (s->task)" This looks fishy - it's still running? So why did you say it crashed? Can you say in which thread it crashed? I.e. run KDevelop from inside GDB wait for the crash then paste the thread apply all bt including the last ~50 lines or so before you inserted that command. This should include also the GDB info about which thread crashed. Generally, can you rule out stack overflow or such stuff? Can you try to run under valgrind?
I don't know why the info about the crashed thread is not there, but this was produced using thread apply all bt. The crashed thread was 17, and I can't rule out stack overflow. Valgrind on OS X is not in a usable state, unfortunately. Is there any other verification I could do to rule out stack overflow?
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
Sorry but without a way to reproduce it, I doubt we can do anything about this issue :(