Bug 374086 - random crash after deleting a message
Summary: random crash after deleting a message
Status: RESOLVED WORKSFORME
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: GIT (master)
Platform: Other Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2016-12-23 16:37 UTC by Christophe Giboudeaux
Modified: 2018-10-27 04:05 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christophe Giboudeaux 2016-12-23 16:37:44 UTC
Just got this with master after deleting a message in KMail :

17:32:07 - kmail2(2020) -  : ASSERT: "m_collections.contains(collectionId)" in file /kde/src/5/akonadiserver/src/core/models/entitytreemodel_p.cpp, line 1253

bt

#7  0x00007f9824093665 in Akonadi::EntityTreeModelPrivate::monitoredItemLinked(Akonadi::Item const&, Akonadi::Collection const&) (this=0x1874810, item=..., collection=...) at /kde/src/5/akonadiserver/src/core/models/entitytreemodel_p.cpp:1253
#8  0x00007f982408914f in Akonadi::EntityTreeModel::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=0x1760c20, _c=QMetaObject::InvokeMetaMethod, _id=28, _a=0x7ffcc63da6d0) at /kde/build/5/akonadiserver/src/core/moc_entitytreemodel.cpp:234
#9  0x00007f982b585681 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5
#10 0x00007f9823fd005f in Akonadi::Monitor::itemLinked(Akonadi::Item const&, Akonadi::Collection const&) (this=0x1802770, _t1=..., _t2=...) at /kde/build/5/akonadiserver/src/core/moc_monitor.cpp:960
#11 0x00007f9823fdd7b1 in Akonadi::MonitorPrivate::emitItemsNotification(Akonadi::Protocol::ItemChangeNotification const&, QVector<Akonadi::Item> const&, Akonadi::Collection const&, Akonadi::Collection const&) (this=0x17b60e0, msg_=..., items=QVector<Akonadi::Item> = {...}, collection=..., collectionDest=...) at /kde/src/5/akonadiserver/src/core/monitor_p.cpp:1054
#12 0x00007f9823fd9cbb in Akonadi::MonitorPrivate::emitNotification(Akonadi::Protocol::ChangeNotification const&) (this=0x17b60e0, msg=...) at /kde/src/5/akonadiserver/src/core/monitor_p.cpp:507
#13 0x00007f9823f8458a in Akonadi::ChangeRecorderPrivate::emitNotification(Akonadi::Protocol::ChangeNotification const&) (this=0x17b60e0, msg=...) at /kde/src/5/akonadiserver/src/core/changerecorder_p.cpp:367
#14 0x00007f9823fdc49b in Akonadi::MonitorPrivate::flushPipeline() (this=0x17b60e0) at /kde/src/5/akonadiserver/src/core/monitor_p.cpp:873
#15 0x00007f9823fdc4fa in Akonadi::MonitorPrivate::dataAvailable() (this=0x17b60e0) at /kde/src/5/akonadiserver/src/core/monitor_p.cpp:882
#16 0x00007f9823fce24a in Akonadi::Monitor::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=0x1802770, _c=QMetaObject::InvokeMetaMethod, _id=43, _a=0x7ffcc63db440) at /kde/build/5/akonadiserver/src/core/moc_monitor.cpp:338
#17 0x00007f982b585681 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5
#18 0x00007f9823faac77 in Akonadi::EntityCacheBase::dataAvailable() (this=0x185d270) at /kde/build/5/akonadiserver/src/core/moc_entitycache_p.cpp:146
#19 0x00007f9823f7d0c8 in Akonadi::EntityListCache<Akonadi::Item, Akonadi::ItemFetchJob, Akonadi::ItemFetchScope>::processResult(KJob*) (this=0x185d270, job=0x251a6c0) at /kde/src/5/akonadiserver/src/core/entitycache_p.h:499
#20 0x00007f9823faaa55 in Akonadi::EntityCacheBase::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=0x185d270, _c=QMetaObject::InvokeMetaMethod, _id=1, _a=0x7ffcc63db760) at /kde/build/5/akonadiserver/src/core/moc_entitycache_p.cpp:80
Comment 1 Daniel Vrátil 2017-01-06 21:48:09 UTC
Looks like a search update in a search collection not known to KMail.

Can you reproduce? Would be helpful to know which Collection it is (at least get the collectionId value) that we get an assert for.

If it's not a mail search collection, then we could try to debug why KMail got a notification for a non-mail collection. If it's a mail search collection, then we can debug why ETM does not know about it.

In the worst case, we can simply handle the situation gracefully and return from ETMPrivate::monitoredItemLinked() early instead of asserting.
Comment 2 Christophe Giboudeaux 2017-01-20 08:13:08 UTC
No, I've no idea how to reproduce and I don't have the core file anymore to look further
Comment 3 Andrew Crouthamel 2018-09-26 22:15:53 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 4 Andrew Crouthamel 2018-10-27 04:05:20 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!