Bug 312071

Summary:	Crash in background parser [Mac OS X / DUContext::findDeclarationsInternal]
Product:	[Applications] kdevelop	Reporter:	Bart Janssens <bart>
Component:	Language Support: CPP (old)	Assignee:	kdevelop-bugs-null
Status:	RESOLVED WAITINGFORINFO
Severity:	crash	CC:	bart
Priority:	NOR
Version First Reported In:	git master
Target Milestone:	---
Platform:	MacPorts
OS:	macOS
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	backtrace Correct back trace

Description Bart Janssens 2012-12-22 13:50:00 UTC

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.

Comment 1 Bart Janssens 2012-12-22 13:50:56 UTC

Created attachment 75969 [details]
backtrace

Comment 2 Bart Janssens 2012-12-22 18:25:20 UTC

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 >"

Comment 3 Milian Wolff 2012-12-22 18:47:08 UTC

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...

Comment 4 Bart Janssens 2012-12-22 19:45:39 UTC

Created attachment 75973 [details]
Correct back trace

Sorry, looks like I managed to upload the wrong file!

Comment 5 Milian Wolff 2012-12-23 13:47:20 UTC

backtrace supplied, changing bug status.

Comment 6 Milian Wolff 2013-01-06 12:29:50 UTC

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?

Comment 7 Bart Janssens 2013-01-20 20:37:41 UTC

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?

Comment 8 Aleix Pol 2013-03-31 00:55:08 UTC

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

Comment 9 Milian Wolff 2013-12-01 16:19:19 UTC

Sorry but without a way to reproduce it, I doubt we can do anything about this issue :(