| Summary: | feeder crashed | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Akonadi | Reporter: | Blackpaw <lindsay.mathieson> |
| Component: | Nepomuk Feeder Agents | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | lindsay.mathieson, me, vkrause |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | GIT (master) | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/kdepim-runtime/ecf676853e27dbddd07ca2c76d87b5fe5971e740 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: | New crash information added by DrKonqi | ||
|
Description
Blackpaw
2013-06-13 09:09:04 UTC
It repeated itself three times now since the original crash. Created attachment 80544 [details]
New crash information added by DrKonqi
akonadi_nepomuk_feeder (4.10) on KDE Platform 4.10.4 using Qt 4.8.4
- What I was doing when the application crashed:
Same as before, letting the feeder index my mails. This happens 100% of time when I reactivate the feeder and from the approx progress of the index I would guess its barfing on the same email every time.
-- Backtrace (Reduced):
#10 0x00007ffd65478b06 in qt_assert (assertion=assertion@entry=0x426554 "mRunningJobs == 0", file=file@entry=0x426330 "/home/lindsay/Projects/akonadi/kdepim-runtime/agents/nepomukfeeder/itemqueue.cpp", line=line@entry=113) at global/qglobal.cpp:2021
#11 0x00000000004167fa in ItemQueue::processBatch (this=this@entry=0x1c60cf8) at /home/lindsay/Projects/akonadi/kdepim-runtime/agents/nepomukfeeder/itemqueue.cpp:113
#12 0x00000000004129a0 in IndexScheduler::processItemQueue (this=this@entry=0x1c60bd0) at /home/lindsay/Projects/akonadi/kdepim-runtime/agents/nepomukfeeder/indexscheduler.cpp:252
#13 0x0000000000413408 in IndexScheduler::qt_static_metacall (_o=0x1c60bd0, _c=<optimized out>, _id=3, _a=0x7fff02651f20) at /home/lindsay/Projects/akonadi/kdepim-runtime/build/agents/nepomukfeeder/indexscheduler.moc:67
[...]
#15 0x00007ffd655993ec in QObject::event (this=0x1c60be8, e=<optimized out>) at kernel/qobject.cpp:1156
I realise this is of no interest to the developer but I added some extra logging to itemqueue.cpp to see what was happening:
--------------------------------------------------------------------------------------------------------
bool ItemQueue::processBatch()
{
kDebug() << "pipline size: " << mItemPipeline.size() << mFetchedItemList.size();
if ( mRunningJobs > 0 ) {//wait until the old graph has been saved
kDebug() << "blocked: " << mRunningJobs;
return false;
}
if ( mRunningJobs != 0 ) {
// added by me
kDebug() << "mRunningJobs == " << mRunningJobs << "!!!!!";
}
Q_ASSERT( mRunningJobs == 0 );
mRunningJobs = 0;
--------------------------------------------------------------------------------------------------------
.xsession-errors
akonadi_nepomuk_feeder(13953) ItemQueue::processBatch: mRunningJobs == -1 !!!!!
ASSERT: "mRunningJobs == 0" in file /home/lindsay/Projects/akonadi/kdepim-runtime/agents/nepomukfeeder/itemqueue.cpp, line 116
--------------------------------------------------------------------------------------------------------
So for some reason mRunningJobs is actually -1, which I presume should never happen.
How thread safe is this stuff? I don't see any use of thread sync primitives.
Added more debug info to Item::QueueClear()
void ItemQueue::clear()
{
if (mRunningJobs > 0)
kDebug() << "CLEAR:mRunningJobs > 0!!!!";
mRunningJobs = 0;
mItemPipeline.clear();
mFetchedItemList.clear();
}
The debug output showed that clear() is being called while jobs are outstanding. Presumably they finish after clear is called and mRunningJobs is decremented to -1.
Have developed a fix and testing it now. Git commit ecf676853e27dbddd07ca2c76d87b5fe5971e740 by Lindsay Mathieson. Committed on 19/06/2013 at 12:30. Pushed by mathieson into branch 'master'. Fix bug in running job count Fixes problem where the count of running jobs becomes less than zero (-1), causing an assert in itemqueue.cpp at line 113 to trigger. This was happening because ItemQueue::clear() was setting the running job count to zero when there was unfinished jobs, when the jobs actually did finish the running job count was decremented to below zero. The batch fixes this by keeping a QList<KJob *> of running jobs, adding them when created and removing when the job finishes (via the result signal). When ItemQueue::clear() is called any outstanding jobs are silently killed and the list cleared. REVIEW: 111089 M +43 -12 agents/nepomukfeeder/itemqueue.cpp M +11 -1 agents/nepomukfeeder/itemqueue.h http://commits.kde.org/kdepim-runtime/ecf676853e27dbddd07ca2c76d87b5fe5971e740 |