About 'invalid item for index' warnings in master

[Milian Wolff]

On Monday 29 December 2014 20:17:14 Kevin Funk wrote:
> Since quite some time now I'm getting a lot of warnings from
> kdevplatform.language during the whole kdevelop session run.
> 
> Log:
> 
> [kdevelop(15289)/(kdevplatform.language)
> KDevelop::TopDUContextDynamicData::DUChainItemStorage::getItemForIndex:
> invalid item for index 784 2922 0
> [kdevelop(15289)/(kdevplatform.language)
> KDevelop::TopDUContextDynamicData::DUChainItemStorage::getItemForIndex:
> invalid item for index 786 2922 0
> [kdevelop(15289)/(kdevplatform.language)
> KDevelop::TopDUContextDynamicData::DUChainItemStorage::getItemForIndex:
> invalid item for index 787 2922 0
> (...)
> 
> Seems like a6e8b89535f2f452bb6e78f7f1ccbbed8d4615e0 caused this and a local
> revert improves the situation and kdevelop is finally able to quickly reload
> data from disk on session startup again.
> 
> @Milian, can you check?

I looked at this while in the train a few days ago. I could not reproduce your 
findings:

a) There is no direct connection between the somehash function and the 
IndexedLocalDeclaration. The latter is a sequential index into the 
topducontext data. The former is only used for set repositories (global item 
repository, modification revision sets, and for oldcpp also include paths and 
macro sets).

b) Reverting the remove of hashlittle, i.e. the commit you point out above, 
still gives me the "invalid item for index" error with oldcpp. But still, with 
or without it, I'm always able to "quickly reload data from disk on session 
startup". So I wonder what kind of bug manifests itself on your side. Are 
there more errors/warnings on the CLI which might give us a hint? Note that 
the warning above, for the "invalid item for index", is only shown when 
something is actually loaded from the disk cache. The error just means you'll 
get a nullptr Declaration* for some index, but no reparse of the file is 
triggered. So that seems to be unrelated?

c) I added a breakpoint to the line where the error is emitted, and could find 
two patterns: One was the cache cleanup, where contexts are destroyed and when 
they are cleaned up also destroy their child declarations. These then, esp. 
the TemplateDeclarations in oldcpp, apparently try to reference already-
deleted contexts and then trigger this error. The other time is somewhere deep 
in the oldcpp ContextBuilder, but afaik also related to TemplateDeclarations. 
Still, both are code paths I'd rather see removed by working more on kdev-
clang, rather than trying to fixup an issue in oldcpp that's been around for 
ages.

d) Finally, exchanging one hash function for another should never trigger and 
change of behavior. Even returning the same number would always "work" - just 
(much) slower. If that is not the case, then we have an issue in the 
ItemRepository or wherever the hash is used. Considering how much this code 
path is used, I somehow doubt it. But experience of course dictates that there 
could still be rare bugs hidden there ;-)

Bye, HTH
-- 
Milian Wolff
mail at milianw.de
http://milianw.de