[Comment from a bug triager]
Bug 259454 is from "akonadi_nepomuk_email_feeder"
Bug 259455 also has a related backtrace, but it is not about an Akonadi app, but Plasma activities manager daemon
Regards

*** Bug 259453 has been marked as a duplicate of this bug. ***

*** Bug 259454 has been marked as a duplicate of this bug. ***

*** Bug 263682 has been marked as a duplicate of this bug. ***

*** Bug 259455 has been marked as a duplicate of this bug. ***

*** Bug 263203 has been marked as a duplicate of this bug. ***

we're seeing this crash in multiple nepomuk-using apps now, some with the same user reporting the same crash in each of these apps. re-assigning to nepomuk.

*** Bug 264504 has been marked as a duplicate of this bug. ***

[Comment from a bug triager]
From bug 268367 (KDE SC 4.6.1):
- What I was doing when the application crashed:
I just logged-in to KDE4.6.1, KMail started (I have it as autostart) and
then Activity manager crashed, at the same time 3 windows of DRkonqi appeared,
sayin that Akonadi Agent crashed as well.

*** Bug 268367 has been marked as a duplicate of this bug. ***

*** Bug 275389 has been marked as a duplicate of this bug. ***

*** Bug 277139 has been marked as a duplicate of this bug. ***

from bug 277139:

-- Information about the crash:
- What I was doing when the application crashed: I had kontact open and
disabled nepomuk because I had to test some things, i.e. virtuoso-t was
constanlty using one core and stuck in a loop, i.e. did not quit even minutes
after nepomuk was already disabled.

I got some notifications about nepomuk not being available anymore. When I
finished anylysing the virtuoso-t process I had to kill it and restart nepomuk.
After this was done I tried to clear the filter in kontact by clicking on the
"x" within the input line. Kontact was busy (I guess coping with nepomuk's
restart) and that's when the crash happened. An akonadi agent (nepomuk email
feeder bug 277138) crashed and kontact crashed.

*** Bug 277503 has been marked as a duplicate of this bug. ***

[Comment from a bug triager]
From bug 278945 (KDE SC 4.7.0):
- What I was doing when the application crashed:
I started dolphin with nepomuk/strigi disabled. Then I started those services
which apparently made dolphin crash.

From bug 279397 (kactivitymanagerd crashed, KDE SC 4.7.0)
- What I was doing when the application crashed:
logging in into a new session of KDE after making some software updates
involving Zypper

*** Bug 278945 has been marked as a duplicate of this bug. ***

*** Bug 279397 has been marked as a duplicate of this bug. ***

*** Bug 280011 has been marked as a duplicate of this bug. ***

*** Bug 281492 has been marked as a duplicate of this bug. ***

Can this be reproduced in KDE 4.6.x or 4.7?

On Wednesday 21 Sep 2011 17:37:47 Sebastian Trueg wrote:
> https://bugs.kde.org/show_bug.cgi?id=251795
> 
> 
> Sebastian Trueg <trueg@kde.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
> Status|UNCONFIRMED                 |ASSIGNED
>                  CC|                            |trueg@kde.org
>      Ever Confirmed|0                           |1
> 
> 
> 
> 
> --- Comment #20 from Sebastian Trueg <trueg kde org>  2011-09-21 17:37:47
> --- Can this be reproduced in KDE 4.6.x or 4.7?

I have not seen this bug on 4.7.1

(In reply to comment #21)
> I have not seen this bug on 4.7.1

Did you experience it before?

I have a coredump from yesterday (despite the appearances, that's kdelibs 4.7):

Program terminated with signal 11, Segmentation fault.
#0  0x00007fd4b74fa5dc in QMutex::lock (this=0x6595d8) at thread/qmutex.cpp:151
151         if (d->recursive) {
(gdb) thread apply all bt

Thread 2 (Thread 0x7fd4a1600700 (LWP 18910)):
#0  0x00007fd4b536a843 in select () at ../sysdeps/unix/syscall-template.S:82
#1  0x00007fd4b75c7301 in QProcessManager::run (this=0x7fd4b7915f80) at io/qprocess_unix.cpp:245
#2  0x00007fd4b74ff015 in QThreadPrivate::start (arg=0x7fd4b7915f80) at thread/qthread_unix.cpp:331
#3  0x00007fd4b726eeb5 in start_thread (arg=0x7fd4a1600700) at pthread_create.c:301
#4  0x00007fd4b53711ad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 1 (Thread 0x7fd4a6be2760 (LWP 18790)):
#0  0x00007fd4b74fa5dc in QMutex::lock (this=0x6595d8) at thread/qmutex.cpp:151
#1  0x00007fd4b8768374 in QMutexLocker (m=0x6595d8, this=<synthetic pointer>) at /usr/include/QtCore/qmutex.h:102
#2  Soprano::Client::SocketHandler::~SocketHandler (this=0x65a8b0, __in_chrg=<optimized out>) at /usr/src/debug/soprano-2.7.50_20110921/client/clientconnection.cpp:58
#3  0x00007fd4b8768479 in Soprano::Client::SocketHandler::~SocketHandler (this=0x65a8b0, __in_chrg=<optimized out>) at /usr/src/debug/soprano-2.7.50_20110921/client/clientconnection.cpp:61
#4  0x00007fd4b74fd457 in QThreadStorageData::set (this=0x6cfd80, p=0x65aa10) at thread/qthreadstorage.cpp:165
#5  0x00007fd4b8765ed0 in qThreadStorage_setLocalData<Soprano::Client::SocketHandler> (d=<optimized out>, t=<optimized out>) at /usr/include/QtCore/qthreadstorage.h:92
#6  setLocalData (t=0x65aa10, this=<optimized out>) at /usr/include/QtCore/qthreadstorage.h:148
#7  Soprano::Client::ClientConnection::socketForCurrentThread (this=0x767ec0) at /usr/src/debug/soprano-2.7.50_20110921/client/clientconnection.cpp:95
#8  0x00007fd4b8765f49 in Soprano::Client::ClientConnection::connectInCurrentThread (this=<optimized out>) at /usr/src/debug/soprano-2.7.50_20110921/client/clientconnection.cpp:754
#9  0x00007fd4b876559a in Soprano::Client::LocalSocketClient::connect (this=0x656cc8, name="/tmp/ksocket-krop/nepomuk-socket") at /usr/src/debug/soprano-2.7.50_20110921/client/localsocketclient.cpp:141
#10 0x00007fd4b6fe80a9 in init (forced=true, this=0x656ca0) at /usr/src/debug/kdelibs-4.7.42_20110921/nepomuk/core/nepomukmainmodel.cpp:102
#11 Nepomuk::MainModel::init (this=0x656be0) at /usr/src/debug/kdelibs-4.7.42_20110921/nepomuk/core/nepomukmainmodel.cpp:176
#12 0x00007fd4b6fe1397 in Nepomuk::ResourceManager::init (this=0x654710) at /usr/src/debug/kdelibs-4.7.42_20110921/nepomuk/core/resourcemanager.cpp:331
#13 0x00007fd4b6fe4445 in Nepomuk::ResourceManagerPrivate::_k_storageServiceInitialized (this=0x6540a0, success=<optimized out>)
    at /usr/src/debug/kdelibs-4.7.42_20110921/nepomuk/core/resourcemanager.cpp:221
#14 0x00007fd4b6fe4545 in Nepomuk::ResourceManager::qt_metacall (this=0x654710, _c=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0x7fffbfb68ce0)
    at /usr/src/debug/kdelibs-4.7.42_20110921/build/nepomuk/resourcemanager.moc:90
#15 0x00007fd4b26de9bb in QDBusConnectionPrivate::deliverCall (this=0x4fdd70, object=0x654710, msg=..., metaTypes=QList<int> = {...}, slotIdx=9) at qdbusintegrator.cpp:942
#16 0x00007fd4b26e7cdf in QDBusCallDeliveryEvent::placeMetaCall (this=<optimized out>, object=<optimized out>) at qdbusintegrator_p.h:103
#17 0x00007fd4b75fbfaa in QObject::event (this=0x654710, e=<optimized out>) at kernel/qobject.cpp:1226
#18 0x00007fd4b5d16be4 in notify_helper (e=0x720340, receiver=0x654710, this=0x48cdb0) at kernel/qapplication.cpp:4481
#19 QApplicationPrivate::notify_helper (this=0x48cdb0, receiver=0x654710, e=0x720340) at kernel/qapplication.cpp:4453
#20 0x00007fd4b5d1ba71 in QApplication::notify (this=0x7fffbfb697b0, receiver=0x654710, e=0x720340) at kernel/qapplication.cpp:4360

(In reply to comment #23)
> I have a coredump from yesterday (despite the appearances, that's kdelibs 4.7):

Is it 4.7.1 or 4.7.0, that is the question.

git snapshots from the 4.7 branch

I can (sort of)reproduce this bug with Project Neon ( which is currently using kdelibs master , and pretty much everything else from master as well ). Currently as soon as i start up my session , nepomukindexer starts hogging all my CPU's ( note this is a 8 core machine ) and then i have to kill the indexer manually via a SIGTERM to bring everything back to normal, giving me a backtrace similar to the one attached ( i reported it as a bug which was marked as a duplicate of this one ).

(In reply to comment #26)
> I can (sort of)reproduce this bug with Project Neon ( which is currently using
> kdelibs master , and pretty much everything else from master as well ).
> Currently as soon as i start up my session , nepomukindexer starts hogging all
> my CPU's ( note this is a 8 core machine ) and then i have to kill the indexer
> manually via a SIGTERM to bring everything back to normal, giving me a
> backtrace similar to the one attached ( i reported it as a bug which was marked
> as a duplicate of this one ).

not related to this bug: can you provide the file that makes nepomukindexer go wild?

On Thursday 22 Sep 2011 13:45:48 Sebastian Trueg wrote:
> https://bugs.kde.org/show_bug.cgi?id=251795
> 
> 
> 
> 
> 
> --- Comment #27 from Sebastian Trueg <trueg kde org>  2011-09-22 13:45:48
> --- (In reply to comment #26)
> 
> > I can (sort of)reproduce this bug with Project Neon ( which is currently
> > using kdelibs master , and pretty much everything else from master as
> > well ). Currently as soon as i start up my session , nepomukindexer
> > starts hogging all my CPU's ( note this is a 8 core machine ) and then
> > i have to kill the indexer manually via a SIGTERM to bring everything
> > back to normal, giving me a backtrace similar to the one attached ( i
> > reported it as a bug which was marked as a duplicate of this one ).
> 
> not related to this bug: can you provide the file that makes nepomukindexer
> go wild?

I noticed (using the openSuse snapshots of -- I presume -- master) that what 
happens is this: some files are apparently slow to index (I must still have 
some of them on my disk, but mostly PDFs generated with inkscape: no text, 
mostly drawings) Then, when the indexer gets stuck, it launches another. Now 
if you have a bunch of these files, you may end up with 20 indexers running. 
Eventually, if you wait long enough, they'll complete their tasks and things 
will go back to normal. But in the meantime, the system gets hammered.

This may or may not be related.

*** Bug 282595 has been marked as a duplicate of this bug. ***

*** Bug 277138 has been marked as a duplicate of this bug. ***

(In reply to comment #28)
> On Thursday 22 Sep 2011 13:45:48 Sebastian Trueg wrote:
> > https://bugs.kde.org/show_bug.cgi?id=251795
> > 
> > 
> > 
> > 
> > 
> > --- Comment #27 from Sebastian Trueg <trueg kde org>  2011-09-22 13:45:48
> > --- (In reply to comment #26)
> > 
> > > I can (sort of)reproduce this bug with Project Neon ( which is currently
> > > using kdelibs master , and pretty much everything else from master as
> > > well ). Currently as soon as i start up my session , nepomukindexer
> > > starts hogging all my CPU's ( note this is a 8 core machine ) and then
> > > i have to kill the indexer manually via a SIGTERM to bring everything
> > > back to normal, giving me a backtrace similar to the one attached ( i
> > > reported it as a bug which was marked as a duplicate of this one ).
> > 
> > not related to this bug: can you provide the file that makes nepomukindexer
> > go wild?
> 
> I noticed (using the openSuse snapshots of -- I presume -- master) that what 
> happens is this: some files are apparently slow to index (I must still have 
> some of them on my disk, but mostly PDFs generated with inkscape: no text, 
> mostly drawings) Then, when the indexer gets stuck, it launches another. Now 
> if you have a bunch of these files, you may end up with 20 indexers running. 
> Eventually, if you wait long enough, they'll complete their tasks and things 
> will go back to normal. But in the meantime, the system gets hammered.
> 
> This may or may not be related.

This should have been fixed already here: https://bugs.kde.org/show_bug.cgi?id=281779. Still it would be very helpful to get such a pdf in order to improve the indexing speed.

Hi Sebastian
Looks like it was trying to index a 700 MB Kubuntu Oneiric amd64 ISO in my home folder which made nepomukindexer go crazy, i hope that helps. Let me know if you need any other info.

*** Bug 258365 has been marked as a duplicate of this bug. ***

*** Bug 237120 has been marked as a duplicate of this bug. ***

*** Bug 278546 has been marked as a duplicate of this bug. ***

*** Bug 261465 has been marked as a duplicate of this bug. ***

*** Bug 283868 has been marked as a duplicate of this bug. ***

*** Bug 284044 has been marked as a duplicate of this bug. ***

*** Bug 285181 has been marked as a duplicate of this bug. ***

Resolving as a duplicate of the newer bug instead of the other way around since I attached a patch to the new one.

*** This bug has been marked as a duplicate of bug 286627 ***

*** Bug 295063 has been marked as a duplicate of this bug. ***