Version: SVN (using Devel) OS: OS X I get the following crash reliably while the background parser tries to process boost's alignment_of.hpp. http://pastebin.com/GBtUupPH Reproducible: Always
David, any idea on this one? Probably an invalid context pointer that is tried to get accessed, or?
btw Till, isn't Valgrind with 3.6 available for Mac OS X now? Could you try to reproduce the bug there?
I guess this is an endless recursion of template instantiation. We might need to enforce some kind of maximum processing depth (there already is for some cases, but maybe not for this one).
I could also not run duchainify on the extracted tarball of boost 1.45, it sooner or later eats all my memory and freezes the whole machine. There is at least one file that does the same when I run gcc -E on it though, so something unrelated in the macro usage there. We generally should try to add more guards everywhere to prevent against such indefinite memory consumption. BTW: Till's example isn't endless, it only has a few houndred (not thousands) of stack frames, which is why both Till and me doubt it's actually a stack overflow. I'd rather assume the context ptr is invalid. But well, it needs to be tested.
It seems strange to have several hundred "valid" instantiation iterations. Maybe each iteration also consumes memory or something like that and it crashes early due to that. It should be impossible that the context is invalidated during the recursion, after all the read-lock should be held. A valgrind log might help anyway.
I believe the C++ standard mandates an instantiation stack of 17 levels. One can customize this in gcc with -ftemplate-depth=N From info gcc, C++ Dialect Options: `-ftemplate-depth-N' Set the maximum instantiation depth for template classes to N. A limit on the template instantiation depth is needed to detect endless recursions during template class instantiation. ANSI/ISO C++ conforming programs must not rely on a maximum depth greater than 17.
Created attachment 70749 [details] GDB run and backtrace when starting kdevelop with a project containing suspect header.
I'd like to add that this still appears to be an issue. Within seconds of typing out #include <boost/accumulators/statistics/weighted_sum.hpp> into my source, kdevelop crashes with a segfault.
I forgot to mention that I'm running kdevelop 4.3.1 (kdevplatform 4.8.1). System is Gentoo Linux. Boost version 1.48.0
@Beau: this looks to this bug report. furthermore I cannot reproduce it. Please file a separate bug report and attach sources that can be used to reproduce the issue. Also add a valgrind log. @Till: still waiting for a valgrind log if you can reproduce it with a current kdevelop on mac. cheers
I'm also suffering from this bug on Gentoo Linux. Even though the OP uses OS X, can we combine our results until something in them suggests that it really is platform specific?
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
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!