Help to understand/fix Kdevelop Crash

[David Nolden]

This might reduce the functionality of the class-browser, because that one
is based purely on the symbol table.

In general, I think this should not be necessary.

I'd try to ensure these things:
* Make sure you don't add function arguments to the symbol table
* Make sure you don't add local variables and local classes within
functions to the symbol table
* Make sure you don't add the same objects from headers multiply
* I think, only in-project stuff should go into the symbol table, and not
stuff from the standard library (need to re-check oldcpp regarding this)

Also, for cases like the linux kernel, there is the "simplified parsing"
mode, which collects only a minimal amount of data (only function names and
classes/namespaces I think). That should probably be implemented for clang
too.

2015-04-18 21:34 GMT+02:00 Milian Wolff <mail at milianw.de>:

> On Saturday 18 April 2015 15:00:31 Lucas Tanure wrote:
> > On Apr 18, 2015 1:40 PM, "Milian Wolff" <mail at milianw.de> wrote:
> > > On Saturday 18 April 2015 16:27:37 Lucas Tanure wrote:
> > > > Hi,
> > > >
> > > > The version of Linux doesn't matter, any version that I used got the
> >
> > same
> >
> > > > behavior.
> > >
> > > Will a release tarball do? Do I need to run configure or anything to
> get
> > > Makefiles generated, or is every setup in such a tarball already?
> >
> > Jus git clone the Linus tree over git.kernel.com
> > Clean tree, do not run make config or anything else.
> > Maybe a tarball from Linux source it's good too.
> >
> > > > I import as a project with Makefile. When the parse gets 50% of all
> >
> > files
> >
> > > > parsed the crash happens, more or less 4gb used of ram. I compiled
> > > > kdevelop, kdev-clang on debug mode.
> > >
> > > Did you need to setup any custom include paths or similar stuff? Or
> >
> > should it
> >
> > > crash even without this?
> >
> > Nope, just git Clone and import.
> > We could talk over Google Hangouts or Skype, I really want this working,
> > but I don't understand the kdevelop and kdev-clang source.
>
> Could you, in the meantime, try the following as a workaround please:
>
> diff --git a/duchain/tuduchain.h b/duchain/tuduchain.h
> index c289758..af2d5aa 100644
> --- a/duchain/tuduchain.h
> +++ b/duchain/tuduchain.h
> @@ -246,6 +246,9 @@ private:
>              decl->setInternalContext(context);
>          setDeclType<CK>(decl, type);
>          setDeclInCtxtData<CK>(cursor, decl);
> +        if (decl->inSymbolTable() && decl->kind() ==
> Declaration::Instance &&
> !decl->isFunctionDeclaration()) {
> +            decl->setInSymbolTable(false);
> +        }
>          return decl;
>      }
>
> But, considering that I could not find any such code in the oldcpp
> codebase, I
> actually wonder whether it's a good idea or not. What it does is ensuring
> no
> global variables or class members (except functions) get added to the
> symbol
> table. This might break other stuff which I have no time to test right now.
> But at least quickopen is not affected as we only care about functions and
> classes there anyways.
>
> Does anyone else have a clue whether the above is good or not?
>
> Bye
>
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150427/b6c670d2/attachment.html>