Help to understand/fix Kdevelop Crash

[Milian Wolff]

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?

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

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

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