Help to understand/fix Kdevelop Crash

[Lucas Tanure]

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.

>
> Thanks, I hope to spent some time on this next week using my faster work
> machine.

Thanks

>
> Cheers, stay tuned
>
> > On Sat, Apr 18, 2015, 13:15 Milian Wolff <mail at milianw.de> wrote:
> > > On Saturday 18 April 2015 12:59:49 Lucas Tanure wrote:
> > > > On Apr 18, 2015 12:52 PM, "Milian Wolff" <mail at milianw.de> wrote:
> > > > > Hey All!
> > > > >
> > > > > On Tuesday 17 March 2015 13:22:05 David Nolden wrote:
> > > > > > Actually, the absolute limit on the size of the item repository
is
> > >
> > > 4GB,
> > >
> > > > > > because the index is a 32 bit number, and there can be 1<<16
> > > > > > buckets,
> > > >
> > > > each
> > > >
> > > > > > of size 1<<16, i.e. 1<<32=4.3GB. Maybe this limit is hit in your
> > >
> > > case.
> > >
> > > > Can
> > > >
> > > > > > you add some assertion which avoids "wrapping" of the bucket
number
> > > > > > (especially of the buckets spanned by the "monster bucket
extent")?
> > > > > >
> > > > > > However, that limit applies to each item repository separately.
In
> > >
> > > your
> > >
> > > > > > case it seems to be the persistent symbol table. IMO it should
never
> > > >
> > > > become
> > > >
> > > > > > that huge, not even for the linux kernel. So I guess this is a
> > >
> > > problem
> > >
> > > > in
> > > >
> > > > > > kdevelop-clang, which puts too much stuff in the symbol table
(just
> > > > > > a
> > > > > > guess).
> > > > >
> > > > > I think this is a very good guess. I've seen similar problems
before
> > > > > in
> > > >
> > > > kdev-
> > > >
> > > > > clang and that should certainly be investigated. Kevin, you added
some
> > > >
> > > > tooling
> > > >
> > > > > around the item repositories recently, no? Can we see what gets
added
> > >
> > > to
> > >
> > > > the
> > > >
> > > > > symbol table and what not?
> > > > >
> > > > > Also, Lucas - you marked
https://bugs.kde.org/show_bug.cgi?id=343950
> > >
> > > as a
> > >
> > > > > duplicate but say here it's actually not. So should I un-mark it
and
> > >
> > > keep
> > >
> > > > it
> > > >
> > > > > open?
> > > >
> > > > Yes keep open. I really think that is the same bug, because the
stack
> > >
> > > trace
> > >
> > > > is the same.
> > > >
> > > > I bought more ram for me, but the issue is still happening.
> > > > I would like that kdev-clang save on the hard drive the parsing
output,
> > > > because it's not good to reparse the files every time.
> > >
> > > It is saving stuff, but when the cache gets (potentially) corrupted
during
> > > a
> > > crash it cannot assume the saved stuff is usable. Thus it kills the
cache
> > > and
> > > starts again and crashes again (in your case). This is unfortunate but
> > > sadly
> > > what we have so far :(
> > >
> > > I'll try to look into this issue over the coming days. Can you give me
> > > some
> > > steps on what you do with the linux kernel? That way I could try to
> > > reproduce
> > > it.
> > >
> > > - which version of the kernel sources do you have?
> > > - how do you import it into kdevelop?
> > > - anything else I should be aware of?
> > >
> > > Thanks
> > > --
> > > Milian Wolff
> > > mail at milianw.de
> > > http://milianw.de
>
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150418/ac25c8f8/attachment.html>