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