Help to understand/fix Kdevelop Crash

[David Nolden]

Try this patch:

diff --git a/serialization/itemrepository.h b/serialization/itemrepository.h
index 7cb0650..1d9612a 100644
--- a/serialization/itemrepository.h
+++ b/serialization/itemrepository.h
@@ -96,7 +96,8 @@ namespace KDevelop {
  */

 enum {
-  ItemRepositoryBucketSize = 1<<16
+  ItemRepositoryBucketSize = 1<<16,
+  ItemRepositoryBucketLimit = 1<<16
 };

 /**
@@ -1298,6 +1299,7 @@ class ItemRepository : public AbstractItemRepository {

           convertMonsterBucket(useBucket, needMonsterExtent);
           m_currentBucket += 1 + needMonsterExtent;
+          Q_ASSERT(m_currentBucket < ItemRepositoryBucketLimit);
           Q_ASSERT(m_buckets[m_currentBucket - 1 - needMonsterExtent] &&
m_buckets[m_currentBucket - 1 - needMonsterExtent]->monsterBucketExtent()
== needMonsterExtent);
         }
         Q_ASSERT(useBucket);
@@ -1389,6 +1391,7 @@ class ItemRepository : public AbstractItemRepository {
           putIntoFreeList(useBucket, bucketPtr);

         ++m_currentBucket;
+        Q_ASSERT(m_currentBucket < ItemRepositoryBucketLimit);
         useBucket = m_currentBucket;
       }
     }

Also, when you reproduce the crash next time, it would be useful if you
could dump the object returned by the "ItemRepository::statistics()"
function of the corresponding item repository, it should be possible to
call that function from within GDB.

Greetings, David


2015-03-18 2:10 GMT+01:00 Lucas Tanure <tanure at linux.com>:

>
>
> --
> Lucas Tanure
> +55 (19) 988176559
>
> On Tue, Mar 17, 2015 at 9:22 AM, David Nolden <
> david.nolden.kdevelop at art-master.de> 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")?
>>
>
> How ? I don't understand this code yet.
>
>
>>
>> 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).
>>
>> Greetings, David
>>
>> 2015-03-15 2:15 GMT+01:00 Lucas Tanure <tanure at linux.com>:
>>
>>> Hi,
>>>
>>> I'm trying to use kdevelop for develop linux kernel, but it's crashing
>>> while parsing.
>>> I imported the main makefile from linux kernel source and after a few
>>> minutes the kdevelop crashes.
>>>
>>> Take a look at:
>>> *kdevelop* *binaries* :
>>> https://www.dropbox.com/s/g01t1uzpkkwihwt/kdevelop.tar.xz?dl=0
>>>
>>> *llvm* *binaries* :
>>> https://www.dropbox.com/s/j8xarqu6leufk8s/llvm.tar.xz?dl=0
>>>
>>> *kdevelop* *log* :
>>> https://www.dropbox.com/s/ke4iovxx8alis9j/kdev.log?dl=0
>>>
>>> *gdb* *coredump* :
>>> https://www.dropbox.com/s/1q7l8pi67kug59r/core.24956.xz?dl=0
>>>
>>> I created the bug:
>>> https://bugs.kde.org/show_bug.cgi?id=343950
>>>
>>> and I thought it was the same as:
>>> https://bugs.kde.org/show_bug.cgi?id=272408 ( not enough memory ram ).
>>> But it's not, it's a real crash. I tested with a 24Gbytes of Ram, and
>>> kdevelop took like 5Gb to parse 50% of linux kernel.
>>>
>>> Please help.
>>> Thanks
>>>
>>> --
>>> Lucas Tanure
>>> +55 (19) 988176559
>>>
>>> _______________________________________________
>>> 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/20150318/65b04f3b/attachment.html>