Help to understand/fix Kdevelop Crash

Lucas Tanure tanure at linux.com
Sat Apr 18 16:27:37 UTC 2015


Hi,

The version of Linux doesn't matter, any version that I used got the same
behavior.

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.

Thanks

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150418/3344d8ea/attachment-0001.html>


More information about the KDevelop-devel mailing list