Jenkins build became unstable: kdelibs_frameworks_qt5 #982
Frank Reininghaus
frank78ac at googlemail.com
Tue Aug 6 18:30:43 UTC 2013
Hi,
2013/8/6 KDE CI System <null at kde.org>:
> See <http://build.kde.org/job/kdelibs_frameworks_qt5/982/changes>
the crash in KDirListerTest has been caused by my recent change
https://git.reviewboard.kde.org/r/111789/
First of all, I apologize for not having run that test before. I had
thought that running KFileItemTest is sufficient because I had assumed
that it is impossible (or at least extremely unlikely) that anyone
relied on the low-level memory layout of a QList<KFileItem>. But I was
wrong :-(
The problem is that "void KCoreDirListerCache::slotUpdateResult( KJob
* j )" has a local variable
QHash<QString, KFileItem*> fileItems
where pointers to the KFileItems in the KFileItemList dir->lstItems
are stored. The function also appends items to dir->lstItems, such
that all pointers in "fileItems" become invalid when a reallocation of
memory is needed.
Moreover, KDirListerCache has a member
QSet<KFileItem*> pendingRemoteUpdates
which might also be problematic (I haven't checked that in detail yet though).
@David: do you know what the reason for storing these pointers,
instead of the KFileItems themselves, is? The only advantage I could
imagine is that this saves updates for the atomic reference counter.
I'm not sure though if that causes more overhead than having a pointer
to the KFileItem, which is in turn a pointer to KFileItemPrivate (and
the overhead that the memory layout of KFileItemList, that
KDirListerCache relies on, causes because the list also stores
pointers to the KFileItems).
IMHO, it looks like using KFileItems, instead of pointers to them, in
KDirListerCache might be the best solution. What do you think?
Sorry for the trouble and best regards
Frank
More information about the Kde-frameworks-devel
mailing list