About 'invalid item for index' warnings in master

[Kevin Funk]

On Saturday 03 January 2015 13:34:56 Milian Wolff wrote:
> 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?

Yep, still got them, but had the impression there were a lot less of them.

> 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

Thanks for the investigation. Maybe it's just the different debug output in 
KF5 that confuses me here. (Usually only prints warnings in KF5, prints 
everything in KDE4).

When I have the time I'll just compare the number of 'invalid item ...' 
warnings in my KF5-based kdevelop against the one from KDE4 and check if 
there's a significant difference...

Anyway: I cannot reproduce my issue with the slow loading from disk anymore, 
so there's no way to debug it either.

Thanks

-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org