Bug 363741 - akonadi server 16.08.1: crashing every few seconds
Summary: akonadi server 16.08.1: crashing every few seconds
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: 5.3.1
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 367846 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-05-31 13:39 UTC by Till Schäfer
Modified: 2016-10-14 02:28 UTC (History)
15 users (show)

See Also:
Latest Commit: http://commits.kde.org/akonadi-search/1e70d63a9439f48b5f1a70accac531a10f4e4239
Version Fixed In: 5.3.2
Sentry Crash Report:

Attachments
log from akonadi console (182.48 KB, application/gzip)
2016-05-31 13:41 UTC, Till Schäfer 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Till Schäfer 2016-05-31 13:39:38 UTC 
Akonadi server keeps crashing every fews seconds and restarts itself. 

I had this bug before and solved it by dropping and re-creation of the akonadi mysql database schema. After the drop akonadi worked as expected for 10 days or so. Now the bug is back again with the same behavior. It happens after an unclean restart of the computer.

I have attached a debug log from akonadi console (the log was closed a few seconds after the crash). Please feel free to contact me if you need further testing. I will keep the crashing instance for some days for analysis requests.

Reproducible: Always

Steps to Reproduce:
1. use kontact and akonadi :-/
Comment 1 Till Schäfer 2016-05-31 13:41:05 UTC 
Created attachment 99282 [details]
log from akonadi console
Comment 2 Till Schäfer 2016-05-31 13:42:19 UTC 
I have further noticed, that the console in which i restarted akonadi with the command "akonadictl restart" is spammed with lines like this: 

  Error in my_thread_global_end(): 3 threads didn't exit
Comment 3 Till Schäfer 2016-05-31 13:45:34 UTC 
another observation: it seems that the akonadi cache is trunkated somehow. I now get messages like 7397 new messages in folder send after akonadi crashes, but there are no "real" new messages in send. Akonadi just seems to loose and re-download them
Comment 4 Till Schäfer 2016-05-31 13:48:43 UTC 
my software stack: 
- qt 5.6.0
- frameworks: 5.22
- kde-apps 16.04.01
- kernel 4.6.0
- mariadb 10.0.25
Comment 5 Till Schäfer 2016-06-03 18:00:20 UTC 
I have attached a debugger and got the following backtrace: 


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fd9d57fa700 (LWP 12610)]
0x00007fd990543828 in ExternalPostList::ExternalPostList (this=0x7fd9b0032620, db=..., source_=0x7fd9d57f8ce0, 
    factor_=1, matcher=0x7fd9d57f8c90) at matcher/externalpostlist.cc:40
40      matcher/externalpostlist.cc: No such file or directory.
(gdb) bt
#0  0x00007fd990543828 in ExternalPostList::ExternalPostList (this=0x7fd9b0032620, db=..., source_=0x7fd9d57f8ce0, 
    factor_=1, matcher=0x7fd9d57f8c90) at matcher/externalpostlist.cc:40
#1  0x00007fd99044c1a2 in Xapian::Internal::QueryPostingSource::postlist (this=<optimized out>, 
    qopt=0x7fd9d57f86e0, factor=1) at api/queryinternal.cc:738
#2  0x00007fd99044a191 in Xapian::Query::Internal::postlist_sub_or_like (this=<optimized out>, ctx=..., 
    qopt=<optimized out>, factor=<optimized out>) at api/queryinternal.cc:625
#3  0x00007fd99044b953 in Xapian::Internal::QueryBranch::do_or_like (this=this@entry=0x7fd9b00315b0, ctx=..., 
    qopt=qopt@entry=0x7fd9d57f86e0, factor=factor@entry=1, elite_set_size=elite_set_size@entry=0, 
    first=first@entry=1) at api/queryinternal.cc:1185
#4  0x00007fd99044bf3a in Xapian::Internal::QueryAndMaybe::postlist (this=0x7fd9b00315b0, qopt=0x7fd9d57f86e0, 
    factor=1) at api/queryinternal.cc:1549
#5  0x00007fd990543a1a in LocalSubMatch::get_postlist (this=0x7fd9b002f300, matcher=0x7fd9d57f8c90, 
    total_subqs_ptr=0x7fd9d57f884c) at matcher/localsubmatch.cc:202
#6  0x00007fd99054a01e in MultiMatch::get_mset (this=this@entry=0x7fd9d57f8c90, first=first@entry=0, 
    maxitems=100000, check_at_least=check_at_least@entry=100000, mset=..., stats=..., mdecider=0x0, sorter=0x0)
    at matcher/multimatch.cc:407
#7  0x00007fd99043984f in Xapian::Enquire::Internal::get_mset (this=0x7fd9b0031400, first=<optimized out>, 
    maxitems=<optimized out>, check_at_least=<optimized out>, check_at_least@entry=0, rset=rset@entry=0x0, 
    mdecider=0x0) at api/omenquire.cc:658
#8  0x00007fd990439bf4 in Xapian::Enquire::get_mset (this=this@entry=0x7fd9d57f8f60, first=<optimized out>, 
    maxitems=<optimized out>, check_at_least=check_at_least@entry=0, rset=rset@entry=0x0, mdecider=0x0)
    at api/omenquire.cc:1015
#9  0x00007fd9901d5d0c in Akonadi::Search::XapianSearchStore::exec (this=0x7fd8d8066640, query=...)
    at /var/tmp/portage/kde-apps/akonadi-search-16.04.1/work/akonadi-search-16.04.1/xapian/xapiansearchstore.cpp:177
#10 0x00007fd9d4ba7ad4 in Akonadi::Search::Query::exec (this=this@entry=0x7fd9d57f91b0)
    at /var/tmp/portage/kde-apps/akonadi-search-16.04.1/work/akonadi-search-16.04.1/core/query.cpp:252
#11 0x00007fd9dc1c51b8 in SearchPlugin::search (this=<optimized out>, akonadiQuery=..., collections=..., 
    mimeTypes=...)
    at /var/tmp/portage/kde-apps/akonadi-search-16.04.1/work/akonadi-search-16.04.1/akonadiplugin/searchplugin.cpp:348
#12 0x0000000000559f92 in Akonadi::Server::SearchRequest::searchPlugins (this=this@entry=0x7fd9d57f97e0)
    at /var/tmp/portage/kde-apps/akonadi-16.04.1/work/akonadi-16.04.1/src/server/search/searchrequest.cpp:112
#13 0x000000000055a273 in Akonadi::Server::SearchRequest::exec (this=this@entry=0x7fd9d57f97e0)
    at /var/tmp/portage/kde-apps/akonadi-16.04.1/work/akonadi-16.04.1/src/server/search/searchrequest.cpp:123
#14 0x00000000004430f3 in Akonadi::Server::SearchManager::updateSearchImpl (this=0xf1faa0, collection=..., 
    cond=<optimized out>)
    at /var/tmp/portage/kde-apps/akonadi-16.04.1/work/akonadi-16.04.1/src/server/search/searchmanager.cpp:350
#15 0x000000000050e080 in Akonadi::Server::SearchManager::qt_static_metacall (_o=<optimized out>, 
    _c=<optimized out>, _id=<optimized out>, _a=<optimized out>)
    at /var/tmp/portage/kde-apps/akonadi-16.04.1/work/akonadi-16.04.1_build/src/server/moc_searchmanager.cpp:108
#16 0x00007fd9e2f564fa in QObject::event (this=0xf1faa0, e=<optimized out>) at kernel/qobject.cpp:1256
#17 0x00007fd9e2f2d895 in doNotify (receiver=<optimized out>, event=<optimized out>)
    at kernel/qcoreapplication.cpp:1090
#18 0x00007fd9e2f2d9ba in QCoreApplication::notify (event=<optimized out>, receiver=<optimized out>, 
---Type <return> to continue, or q <return> to quit---
    this=<optimized out>) at kernel/qcoreapplication.cpp:1076
#19 QCoreApplication::notifyInternal2 (receiver=0xf1faa0, event=event@entry=0x7fd9b0010310)
    at kernel/qcoreapplication.cpp:1015
#20 0x00007fd9e2f2fc73 in QCoreApplication::sendEvent (event=0x7fd9b0010310, receiver=<optimized out>)
    at kernel/qcoreapplication.h:227
#21 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, 
    data=0xf33e90) at kernel/qcoreapplication.cpp:1650
#22 0x00007fd9e2f30218 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, 
    event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1508
#23 0x00007fd9e2f7a7f3 in postEventSourceDispatch (s=0x7fd9b00012d0) at kernel/qeventdispatcher_glib.cpp:270
#24 0x00007fd9e072bcad in g_main_dispatch (context=0x7fd9b0000990)
    at /var/tmp/portage/dev-libs/glib-2.46.2-r3/work/glib-2.46.2/glib/gmain.c:3154
#25 g_main_context_dispatch (context=context@entry=0x7fd9b0000990)
    at /var/tmp/portage/dev-libs/glib-2.46.2-r3/work/glib-2.46.2/glib/gmain.c:3769
#26 0x00007fd9e072bf90 in g_main_context_iterate (context=context@entry=0x7fd9b0000990, block=block@entry=1, 
    dispatch=dispatch@entry=1, self=<optimized out>)
    at /var/tmp/portage/dev-libs/glib-2.46.2-r3/work/glib-2.46.2/glib/gmain.c:3840
#27 0x00007fd9e072c03c in g_main_context_iteration (context=0x7fd9b0000990, may_block=1)
    at /var/tmp/portage/dev-libs/glib-2.46.2-r3/work/glib-2.46.2/glib/gmain.c:3901
#28 0x00007fd9e2f7a867 in QEventDispatcherGlib::processEvents (this=0x7fd9b00008c0, flags=...)
    at kernel/qeventdispatcher_glib.cpp:417
#29 0x00007fd9e2f2c5ca in QEventLoop::exec (this=this@entry=0x7fd9d57f9e00, flags=..., flags@entry=...)
    at kernel/qeventloop.cpp:204
#30 0x00007fd9e2d84c94 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:503
#31 0x00007fd9e2d8943c in QThreadPrivate::start (arg=0xf34e90) at thread/qthread_unix.cpp:340
#32 0x00007fd9e21c1434 in start_thread (arg=0x7fd9d57fa700) at pthread_create.c:334
#33 0x00007fd9e24bf50d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Comment 6 Till Schäfer 2016-06-03 18:11:26 UTC 
I have upgraded from xapian 1.3.6 to xapian 1.3.7, because this seems to be xapian related 
 -> with no effect (still crashes)
Comment 7 Till Schäfer 2016-06-03 18:55:49 UTC 
deleting search_db does not help either
Comment 8 Jan-Matthias Braun 2016-06-30 22:23:27 UTC 
Hi!

I am seeing similar behaviour since 16.04.x, and checked up to 16.04.2 and 16.04-git.
I am using qt 5.7, xapian 1.4, frameworks 5.23, and mariadb 10.1.14 on gentoo, too.

One of my backtraces looks like this and is only partially usable:
0: akonadiserver() [0x4ac960]
1: akonadiserver() [0x4acc5f]
2: /lib64/libc.so.6(+0x33250) [0x7f025e5b3250]
3: /usr/lib64/libxapian.so.30(+0x1b2508) [0x7f0248531508]
4: /usr/lib64/libxapian.so.30(+0x7554b) [0x7f02483f454b]
5: /usr/lib64/libxapian.so.30(_ZNK6Xapian5Query8Internal20postlist_sub_or_likeERNS_8Internal9OrContextEP14QueryOptimiserd+0x21) [0x7f02483f1e21]
6: /usr/lib64/libxapian.so.30(+0x745a3) [0x7f02483f35a3]
7: /usr/lib64/libxapian.so.30(+0x74e1a) [0x7f02483f3e1a]
8: /usr/lib64/libxapian.so.30(+0x1b266a) [0x7f024853166a]
9: /usr/lib64/libxapian.so.30(+0x1c2991) [0x7f0248541991]
10: /usr/lib64/libxapian.so.30(_ZNK6Xapian7Enquire8Internal8get_msetEjjjPKNS_4RSetEPKNS_12MatchDeciderE+0x1c1) [0x7f02483dd8f1]
11: /usr/lib64/libxapian.so.30(_ZNK6Xapian7Enquire8get_msetEjjjPKNS_4RSetEPKNS_12MatchDeciderE+0x24) [0x7f02483ddc34]
12: /usr/lib64/libKF5AkonadiSearchXapian.so.5(_ZN7Akonadi6Search17XapianSearchStore4execERKNS0_5QueryE+0x8b6) [0x7f02481725d6]
13: /usr/lib64/libKF5AkonadiSearchCore.so.5(_ZN7Akonadi6Search5Query4execEv+0x245) [0x7f0258235a55]
14: /usr/lib64/qt5/plugins/akonadi/akonadi_search_plugin.so(+0x400c) [0x7f025844000c]
15: akonadiserver() [0x4cba6f]
16: akonadiserver() [0x44aaa8]
17: akonadiserver() [0x4835d0]
18: /usr/lib64/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0xe9) [0x7f025e085aa9]
19: /usr/lib64/libQt5Core.so.5(_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent+0xfb) [0x7f025e059b5b]
20: /usr/lib64/libQt5Core.so.5(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x2db) [0x7f025e05c26b]
21: /usr/lib64/libQt5Core.so.5(+0x2de3f3) [0x7f025e0ad3f3]
22: /usr/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x297) [0x7f025c86eb17]
23: /usr/lib64/libglib-2.0.so.0(+0x294f8) [0x7f025c86f4f8]
24: /usr/lib64/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f025c86f68c]
25: /usr/lib64/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x5f) [0x7f025e0ad7ff]
26: /usr/lib64/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0xfa) [0x7f025e057b1a]
27: /usr/lib64/libQt5Core.so.5(_ZN7QThread4execEv+0xb4) [0x7f025de79214]
28: /usr/lib64/libQt5Core.so.5(+0xaee78) [0x7f025de7de78]
29: /lib64/libpthread.so.0(+0x7434) [0x7f025d99c434]
30: /lib64/libc.so.6(clone+0x6d) [0x7f025e667ded]

Now I have installed all debug symbols, but now I can only see mini-backtraces with even less information:
0: akonadiserver() [0x572666]
1: akonadiserver() [0x572982]
2: /lib64/libc.so.6(+0x33250) [0x7fa0e1fe9250]

which leaves me at a loss for useful info. (I am not even getting dr konqi, I have to grab the debug info from the akonadi logs.)

I am using a bunch of imap-servers including one akonadi-ews account. I have contacts and calendars in owncloud. These seem to get disabled all the while.

What can I do to improve debugging information?

Cheers,

Jan
Comment 9 Jan-Matthias Braun 2016-07-01 15:40:19 UTC 
Connecting into the running process indeed provides a better backtrace, although -- why? :-)

Here it is:
#0  0x0000000000000000 in ?? ()
#1  0x00007f6ef42d333b in ExternalPostList::ExternalPostList (this=0x7f6f0835a170, db=..., source_=<optimized out>, factor_=<optimized out>, 
    matcher=0x7f6f137fcd30) at matcher/externalpostlist.cc:40
#2  0x00007f6ef41e6d6b in Xapian::Internal::QueryPostingSource::postlist (this=<optimized out>, qopt=0x7f6f137fc650, factor=1)
    at api/queryinternal.cc:739
#3  0x00007f6ef41e50a1 in Xapian::Query::Internal::postlist_sub_xor (this=<optimized out>, ctx=..., qopt=<optimized out>, 
    factor=<optimized out>) at api/queryinternal.cc:634
#4  0x00007f6ef41e6553 in Xapian::Internal::QueryBranch::do_or_like (this=this@entry=0x7f6f0807b490, ctx=..., 
    qopt=qopt@entry=0x7f6f137fc650, factor=factor@entry=1, elite_set_size=elite_set_size@entry=0, first=first@entry=1)
    at api/queryinternal.cc:1186
#5  0x00007f6ef41e6b1a in Xapian::Internal::QueryAndMaybe::postlist (this=0x7f6f0807b490, qopt=0x7f6f137fc650, factor=1)
    at api/queryinternal.cc:1550
#6  0x00007f6ef42d35fa in LocalSubMatch::get_postlist (this=0x7f6f0807af50, matcher=0x7f6f137fcd30, total_subqs_ptr=0x7f6f137fc7bc)
    at matcher/localsubmatch.cc:204
#7  0x00007f6ef42d9a51 in MultiMatch::get_mset (this=this@entry=0x7f6f137fcd30, first=first@entry=0, maxitems=100000, 
    check_at_least=check_at_least@entry=100000, mset=..., stats=..., mdecider=0x0, sorter=0x0) at matcher/multimatch.cc:419
#8  0x00007f6ef41d55e1 in Xapian::Enquire::Internal::get_mset (this=0x7f6f0807ad10, first=<optimized out>, maxitems=<optimized out>, 
    check_at_least=<optimized out>, check_at_least@entry=0, rset=rset@entry=0x0, mdecider=0x0) at api/omenquire.cc:548
#9  0x00007f6ef41d5924 in Xapian::Enquire::get_mset (this=this@entry=0x7f6f137fd050, first=<optimized out>, maxitems=<optimized out>, 
    check_at_least=check_at_least@entry=0, rset=rset@entry=0x0, mdecider=0x0) at api/omenquire.cc:906
#10 0x00007f6ee05e968d in Akonadi::Search::XapianSearchStore::exec (this=0x7f6ef009bf50, query=...)
    at /var/tmp/portage/kde-apps/akonadi-search-16.04.49.9999/work/akonadi-search-16.04.49.9999/xapian/xapiansearchstore.cpp:177
#11 0x00007f6f12df8065 in Akonadi::Search::Query::exec (this=this@entry=0x7f6f137fd2c0)
    at /var/tmp/portage/kde-apps/akonadi-search-16.04.49.9999/work/akonadi-search-16.04.49.9999/core/query.cpp:252
#12 0x00007f6f180fff7d in SearchPlugin::search (this=<optimized out>, akonadiQuery=..., collections=..., mimeTypes=...)
    at /var/tmp/portage/kde-apps/akonadi-search-16.04.49.9999/work/akonadi-search-16.04.49.9999/akonadiplugin/searchplugin.cpp:348
#13 0x000000000055b4eb in Akonadi::Server::SearchRequest::searchPlugins (this=this@entry=0x7f6f137fd900)
    at /var/tmp/portage/kde-apps/akonadi-16.04.49.9999/work/akonadi-16.04.49.9999/src/server/search/searchrequest.cpp:112
#14 0x000000000055b893 in Akonadi::Server::SearchRequest::exec (this=this@entry=0x7f6f137fd900)
    at /var/tmp/portage/kde-apps/akonadi-16.04.49.9999/work/akonadi-16.04.49.9999/src/server/search/searchrequest.cpp:123
#15 0x0000000000444788 in Akonadi::Server::SearchManager::updateSearchImpl (this=0x27003f0, collection=..., cond=<optimized out>)
    at /var/tmp/portage/kde-apps/akonadi-16.04.49.9999/work/akonadi-16.04.49.9999/src/server/search/searchmanager.cpp:350
#16 0x00007f6f1f8deaa9 in QObject::event (this=0x27003f0, e=<optimized out>) at kernel/qobject.cpp:1263
#17 0x00007f6f1f8b2b5b in doNotify (event=0x7f6f08031ea0, receiver=0x27003f0) at kernel/qcoreapplication.cpp:1063
#18 QCoreApplication::notify (event=<optimized out>, receiver=<optimized out>, this=<optimized out>) at kernel/qcoreapplication.cpp:1049
#19 QCoreApplication::notifyInternal2 (receiver=0x27003f0, event=event@entry=0x7f6f08031ea0) at kernel/qcoreapplication.cpp:988
#20 0x00007f6f1f8b526b in QCoreApplication::sendEvent (event=0x7f6f08031ea0, receiver=<optimized out>) at kernel/qcoreapplication.h:231
#21 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x2700600)
    at kernel/qcoreapplication.cpp:1649
#22 0x00007f6f1f8b56d8 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0)
    at kernel/qcoreapplication.cpp:1503
#23 0x00007f6f1f9063f3 in postEventSourceDispatch (s=0x7f6f080012d0) at kernel/qeventdispatcher_glib.cpp:276
#24 0x00007f6f1dd2eb17 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#25 0x00007f6f1dd2f4f8 in g_main_context_iterate.isra () from /usr/lib64/libglib-2.0.so.0
#26 0x00007f6f1dd2f68c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#27 0x00007f6f1f9067ff in QEventDispatcherGlib::processEvents (this=0x7f6f080008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#28 0x00007f6f1f8b0b1a in QEventLoop::exec (this=this@entry=0x7f6f137fde80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:210
#29 0x00007f6f1f6d2214 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:507
#30 0x00007f6f1f6d6e78 in QThreadPrivate::start (arg=0x27004c0) at thread/qthread_unix.cpp:344
#31 0x00007f6f1ee5c434 in start_thread () from /lib64/libpthread.so.0
#32 0x00007f6f1f158ded in clone () from /lib64/libc.so.6
Comment 10 Jan-Matthias Braun 2016-07-01 16:02:42 UTC 
Ok, I have seen this one three times in a row, now,
Comment 11 Jan-Matthias Braun 2016-07-01 18:31:33 UTC 
I do see the same backtrace for xapian 1.3.7.
Comment 12 Jan-Matthias Braun 2016-07-04 12:09:27 UTC 
Okay, I was able to remove a very reproducible crash (with the above mentioned segfault) during startup of akonadi (without any client running) by removing a search from the search folder in kmail. Since then, it is running for at least eight minutes (!) now and I haven't seen a SEGV up to now.

By the way, is it normal, that different searches have the same name? In the logs I am seeing the
Executing search "foo-1186278907-bar"
lines. And the crashing search had the same name, as the search running before, which was much, much simpler. And checking now I see, that different searches often have the same search name in the logs, although from time to time the name seems to change.

Revisiting older logs, the crash always happend with a reused search-name. But I cannot tell if it was the same search, always, because only now I went to instrument the code around the backtrace end in the akonadi-search code (xapian/xapiansearchstore.cpp:177) with lots of output.
Comment 13 Jan-Matthias Braun 2016-07-04 14:55:36 UTC 
it looks like my problem is somehow related to akonadi/kmail producing and not coping with invalid xapian searches.

Right now, I have not seen another akonadi crash. The search that was crashing akonadi had a debug output representation (using the qdebug overload of operator << on term()) over half a screen, i.e., many lines with many many columns. I have no Idea where it came from -- and now it is gone.
Comment 14 Sven Eden 2016-07-05 13:59:29 UTC 
I tried this and removed the search folder. After a restart of both akonadi and kontact (I had gdb hooked to the akonadiserver process) and trying to do a search, gdb caught a SIGSEGV with the following trace:

--------
Thread 60 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fd009ffb700 (LWP 17593)]
0x00007fcfe854b9a8 in vtable for Xapian::Internal::QueryTerm () from /usr/lib64/libxapian-1.3.so.8
(gdb) bt
#0  0x00007fcfe854b9a8 in vtable for Xapian::Internal::QueryTerm () from /usr/lib64/libxapian-1.3.so.8
#1  0x00007fcfe82a301b in ExternalPostList::ExternalPostList (this=0x7fcff009f1e0, db=..., source_=<optimized out>, 
    factor_=<optimized out>, matcher=0x7fd009ff9d10) at matcher/externalpostlist.cc:40
#2  0x00007fcfe81b5d4b in Xapian::Internal::QueryPostingSource::postlist (this=<optimized out>, qopt=0x7fd009ff9630, factor=1)
    at api/queryinternal.cc:739
#3  0x00007fcfe81b40b1 in Xapian::Query::Internal::postlist_sub_xor (this=<optimized out>, ctx=..., qopt=<optimized out>, 
    factor=<optimized out>) at api/queryinternal.cc:634
#4  0x00007fcfe81b5533 in Xapian::Internal::QueryBranch::do_or_like (this=this@entry=0x7fcff001bd60, ctx=..., 
    qopt=qopt@entry=0x7fd009ff9630, factor=factor@entry=1, elite_set_size=elite_set_size@entry=0, first=first@entry=1)
    at api/queryinternal.cc:1186
#5  0x00007fcfe81b5afa in Xapian::Internal::QueryAndMaybe::postlist (this=0x7fcff001bd60, qopt=0x7fd009ff9630, factor=1)
    at api/queryinternal.cc:1550
#6  0x00007fcfe82a32da in LocalSubMatch::get_postlist (this=0x7fcff009a6c0, matcher=0x7fd009ff9d10, total_subqs_ptr=0x7fd009ff979c)
    at matcher/localsubmatch.cc:204
#7  0x00007fcfe82a9741 in MultiMatch::get_mset (this=this@entry=0x7fd009ff9d10, first=first@entry=0, maxitems=95894, 
    check_at_least=check_at_least@entry=95894, mset=..., stats=..., mdecider=0x0, sorter=0x0) at matcher/multimatch.cc:419
#8  0x00007fcfe81a4641 in Xapian::Enquire::Internal::get_mset (this=0x7fcff009a830, first=<optimized out>, 
    maxitems=<optimized out>, check_at_least=<optimized out>, check_at_least@entry=0, rset=rset@entry=0x0, mdecider=0x0)
    at api/omenquire.cc:548
#9  0x00007fcfe81a4984 in Xapian::Enquire::get_mset (this=this@entry=0x7fd009ffa030, first=<optimized out>, 
    maxitems=<optimized out>, check_at_least=check_at_least@entry=0, rset=rset@entry=0x0, mdecider=0x0) at api/omenquire.cc:906
#10 0x00007fcfe05e967d in Akonadi::Search::XapianSearchStore::exec (this=0x7fcff003fe70, query=...)
    at /home/portage/kde-apps/akonadi-search-16.04.2/work/akonadi-search-16.04.2/xapian/xapiansearchstore.cpp:177
#11 0x00007fd00919e2e5 in Akonadi::Search::Query::exec (this=this@entry=0x7fd009ffa2a0)
    at /home/portage/kde-apps/akonadi-search-16.04.2/work/akonadi-search-16.04.2/core/query.cpp:252
#12 0x00007fd0095f5f6d in SearchPlugin::search (this=<optimized out>, akonadiQuery=..., collections=..., mimeTypes=...)
    at /home/portage/kde-apps/akonadi-search-16.04.2/work/akonadi-search-16.04.2/akonadiplugin/searchplugin.cpp:348
#13 0x000000000053ed1d in Akonadi::Server::SearchRequest::searchPlugins (this=this@entry=0x7fd009ffa880)
    at /home/portage/kde-apps/akonadi-16.04.2/work/akonadi-16.04.2/src/server/search/searchrequest.cpp:112
#14 0x000000000053ef7f in Akonadi::Server::SearchRequest::exec (this=this@entry=0x7fd009ffa880)
    at /home/portage/kde-apps/akonadi-16.04.2/work/akonadi-16.04.2/src/server/search/searchrequest.cpp:123
#15 0x0000000000443944 in Akonadi::Server::SearchManager::updateSearchImpl (this=<optimized out>, collection=..., 
    cond=0x7fceeaffc4e0) at /home/portage/kde-apps/akonadi-16.04.2/work/akonadi-16.04.2/src/server/search/searchmanager.cpp:350
#16 0x00000000004fbea5 in Akonadi::Server::SearchManager::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, 
    _id=<optimized out>, _a=<optimized out>)
    at /home/portage/kde-apps/akonadi-16.04.2/work/akonadi-16.04.2_build/src/server/moc_searchmanager.cpp:108
#17 0x00007fd0165f8711 in QObject::event (this=0x27ac890, e=<optimized out>) at kernel/qobject.cpp:1256
#18 0x00007fd0165cfaaa in doNotify (receiver=<optimized out>, event=<optimized out>) at kernel/qcoreapplication.cpp:1090
#19 0x00007fd0165cfbda in QCoreApplication::notifyInternal2 (receiver=0x27ac890, event=event@entry=0x7fceec0deef0)
    at kernel/qcoreapplication.cpp:1015
#20 0x00007fd0165d1c2a in QCoreApplication::sendEvent (event=0x7fceec0deef0, receiver=<optimized out>)
    at kernel/qcoreapplication.h:225
#21 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x27ab840)
    at kernel/qcoreapplication.cpp:1650
#22 0x00007fd0165d20e8 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0)
    at kernel/qcoreapplication.cpp:1508
#23 0x00007fd01661ec13 in postEventSourceDispatch (s=0x7fcff00012d0) at kernel/qeventdispatcher_glib.cpp:270
#24 0x00007fd013da07f7 in g_main_dispatch (context=0x7fcff0000990)
    at /home/portage/dev-libs/glib-2.46.2-r3/work/glib-2.46.2/glib/gmain.c:3154
#25 g_main_context_dispatch (context=context@entry=0x7fcff0000990)
    at /home/portage/dev-libs/glib-2.46.2-r3/work/glib-2.46.2/glib/gmain.c:3769
#26 0x00007fd013da0a50 in g_main_context_iterate (context=context@entry=0x7fcff0000990, block=block@entry=1, 
    dispatch=dispatch@entry=1, self=<optimized out>) at /home/portage/dev-libs/glib-2.46.2-r3/work/glib-2.46.2/glib/gmain.c:3840
#27 0x00007fd013da0afc in g_main_context_iteration (context=0x7fcff0000990, may_block=may_block@entry=1)
    at /home/portage/dev-libs/glib-2.46.2-r3/work/glib-2.46.2/glib/gmain.c:3901
#28 0x00007fd01661ec8f in QEventDispatcherGlib::processEvents (this=0x7fcff00008c0, flags=...)
    at kernel/qeventdispatcher_glib.cpp:417
#29 0x00007fd0165cea3a in QEventLoop::exec (this=this@entry=0x7fd009ffae80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#30 0x00007fd016427ec4 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:500
#31 0x00007fd01642c36c in QThreadPrivate::start (arg=0x27ab700) at thread/qthread_unix.cpp:341
#32 0x00007fd0157c6424 in start_thread (arg=0x7fd009ffb700) at pthread_create.c:334
#33 0x00007fd015ac43bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

--------

Continuing results in a lot of exited threads and an eventual crash of the akonadiserver process:

--------
[Inferior 1 (process 17584) exited with code 0377]
--------

From here on akonadiserver crashes every few minutes with the following akonadi log entries:

--------
Executing search "searchUpdate-1467726031"
QVariant(QString, "2457575") 2457575
"[\n0: akonadiserver() [0x554200]\n1: akonadiserver() [0x55441e]\n2: /lib64/libc.so.6(+0x33380) [0x7f60ec451380]\n3: /usr/lib64/libxapian-1.3.so.8(+0x3fe6b8) [0x7f60ac5e56b8]\n]\n"
akonadicore_log: Socket error occurred: "QLocalSocket: The connection was closed by the remote end"
(...)
akonadicore_log: Socket error occurred: "QLocalSocket: The connection was closed by the remote end"
ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unbekannter Fehler)
--------
Comment 15 Daniel Vrátil 2016-07-20 21:12:31 UTC 
Please try removing content of ~/.local/share/akonadi/search_db and ~/.local/share/baloo/{calendars,collections,contacts,email,emailContacts,notes} (if if exists)

This unfortunately is Xapian crashing on its own (probably corrupted) database, something that is currently out of our control.
Comment 16 Till Schäfer 2016-07-20 21:17:06 UTC 
by why does a mysql schema drop/create helps in this case?
Comment 17 Christian Boltz 2016-08-21 12:07:18 UTC 
(In reply to Daniel Vrátil from comment #15)
> Please try removing content of ~/.local/share/akonadi/search_db and
> ~/.local/share/baloo/{calendars,collections,contacts,email,emailContacts,
> notes} (if if exists)

I hit this bug (on openSUSE Tumbleweed) and tried this (I moved akonadi/search_db away and didn't have the mentioned baloo files because I have most of baloo disabled).

After starting akonadi and kmail, unfortunately it only took a minute until akonadi restarted itsself again :-(

Note: this started after Akonadi and Baloo were rebuilt against libxapian30 (xapian 1.4.0). With the previous libxapian22 (xapian 1.2.23), everything worked without problems.
Comment 18 Ian 2016-08-21 13:11:12 UTC 
i've got akonadi restarting itself when feels like as well and kmail2 also crashes with seg fault 11 but i don;t know if they are related.  I've only had this issue since kmail2 ver 5.3.0 was downloaded and installed.  i've logged it here https://bugs.kde.org/show_bug.cgi?id=367632
Comment 19 Aitor 2016-08-21 14:43:33 UTC 
I'm seeing akonadiserver coredumping repeatedly as well on OpenSUSE Tumbleweed. 
$ coredumpctl list COREDUMP_COMM=akonadiserver
TIME                            PID   UID   GID SIG PRESENT EXE
sáb 2016-08-20 17:08:31 IST   3345  1004  1004  11   /usr/bin/akonadiserver
sáb 2016-08-20 18:06:23 IST  11612  1004  1004  11   /usr/bin/akonadiserver
sáb 2016-08-20 19:48:13 IST   9044  1004  1004  11   /usr/bin/akonadiserver
sáb 2016-08-20 20:52:21 IST  11546  1004  1004  11   /usr/bin/akonadiserver
sáb 2016-08-20 20:56:26 IST  15596  1004  1004  11   /usr/bin/akonadiserver
sáb 2016-08-20 20:58:45 IST  17769  1004  1004  11   /usr/bin/akonadiserver
sáb 2016-08-20 21:04:58 IST  20943  1004  1004  11   /usr/bin/akonadiserver
sáb 2016-08-20 21:07:09 IST  21753  1004  1004  11   /usr/bin/akonadiserver
sáb 2016-08-20 21:08:31 IST  22413  1004  1004  11   /usr/bin/akonadiserver
sáb 2016-08-20 22:33:24 IST  10901  1004  1004  11   /usr/bin/akonadiserver
sáb 2016-08-20 22:38:27 IST  13131  1004  1004  11   /usr/bin/akonadiserver
sáb 2016-08-20 22:43:31 IST  14567  1004  1004  11   /usr/bin/akonadiserver
sáb 2016-08-20 22:54:25 IST  22114  1004  1004  11   /usr/bin/akonadiserver
sáb 2016-08-20 22:54:59 IST  23583  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 01:54:48 IST    2790  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 01:57:24 IST    3918  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 02:03:47 IST    8106  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 02:06:56 IST    9122  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 02:08:22 IST   11547  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 02:31:25 IST   19402  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 02:49:12 IST   23853  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 02:50:40 IST   24263  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 02:52:12 IST   24672  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 15:00:43 IST    7764  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 15:06:37 IST   11212  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 15:07:09 IST   11870  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 15:11:17 IST   12143  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 15:25:41 IST   19825  1004  1004  11   /usr/bin/akonadiserver
dom 2016-08-21 15:29:20 IST   21604  1004  1004  11   /usr/bin/akonadiserver

All leaving the same backtrace:
$ coredumpctl gdb 11870
           PID: 11870 (akonadiserver)
           UID: 1004 (user)
           GID: 1004 (user)
        Signal: 11 (SEGV)
     Timestamp: dom 2016-08-21 15:06:23 IST (14min ago)
  Command Line: akonadiserver
    Executable: /usr/bin/akonadiserver
 Control Group: /
         Slice: -.slice
       Boot ID: 3c838f6cf33a4d4288cfef8de81c1a84
    Machine ID: 0a280ef085a9a213e42acac8576af948
      Hostname: <hostname>
      Coredump: /var/lib/systemd/coredump/core.akonadiserver.1004.3c838f6cf33a4d4288cfef8de81c1a84.11870.1471788383000000.xz
       Message: Process 11870 (akonadiserver) of user 1004 dumped core.

GNU gdb (GDB; openSUSE Tumbleweed) 7.11.1
[...]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `akonadiserver'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  x86_64_fallback_frame_state (context=0x7fe67caed240, context=0x7fe67caed240, fs=0x7fe67caed330) at ./md-unwind-support.h:58
58      ./md-unwind-support.h: No existe el fichero o el directorio.
[Current thread is 1 (Thread 0x7fe67caf0700 (LWP 11884))]
Missing separate debuginfos, use: zypper install akonadi-server-debuginfo-16.04.3-2.1.x86_64
(gdb) bt
#0  0x00007fe68535a21b in uw_frame_state_for (context=0x7fe67caed240, context=0x7fe67caed240, fs=0x7fe67caed330) at ./md-unwind-support.h:58
#1  0x00007fe68535a21b in uw_frame_state_for (context=context@entry=0x7fe67caed240, fs=fs@entry=0x7fe67caed330) at ../../../libgcc/unwind-dw2.c:1249
#2  0x00007fe68535bbb8 in _Unwind_Backtrace (trace=0x7fe68509e210 <backtrace_helper>, trace_argument=0x7fe67caed4f0) at ../../../libgcc/unwind.inc:290
#3  0x00007fe68509e37f in __GI___backtrace (array=<optimized out>, size=<optimized out>) at ../sysdeps/x86_64/backtrace.c:110
#4  0x0000000000574fe6 in  ()
#5  0x0000000000575300 in  ()
#6  0x00007fe684fdd9f0 in <signal handler called> () at /lib64/libc.so.6
#7  0x0000000000000018 in  ()
#8  0x00007fe6545445cb in  () at /usr/lib64/libxapian.so.30
#9  0x00007fe654456730 in  () at /usr/lib64/libxapian.so.30
#10 0x00007fe654454c41 in Xapian::Query::Internal::postlist_sub_or_like(Xapian::Internal::OrContext&, QueryOptimiser*, double) const () at /usr/lib64/libxapian.so.30
#11 0x00007fe654455f1c in  () at /usr/lib64/libxapian.so.30
#12 0x00007fe6544564e1 in  () at /usr/lib64/libxapian.so.30
#13 0x00007fe65454488a in  () at /usr/lib64/libxapian.so.30
#14 0x00007fe65454abb6 in  () at /usr/lib64/libxapian.so.30
#15 0x00007fe65444430f in Xapian::Enquire::Internal::get_mset(unsigned int, unsigned int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) const () at /usr/lib64/libxapian.so.30
#16 0x00007fe654444654 in Xapian::Enquire::get_mset(unsigned int, unsigned int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) const () at /usr/lib64/libxapian.so.30
#17 0x00007fe6541db9bd in Akonadi::Search::XapianSearchStore::exec(Akonadi::Search::Query const&) () at /usr/lib64/libKF5AkonadiSearchXapian.so.5
#18 0x00007fe677ba9cd1 in Akonadi::Search::Query::exec() () at /usr/lib64/libKF5AkonadiSearchCore.so.5
#19 0x00007fe67c0eb57a in  () at /usr/lib64/qt5/plugins/akonadi/akonadi_search_plugin.so
#20 0x000000000055e0c7 in  ()
#21 0x000000000055e453 in  ()
#22 0x0000000000449487 in  ()
#23 0x00007fe685ba2cf9 in QObject::event(QEvent*) (this=0x1b0e3d0, e=<optimized out>) at kernel/qobject.cpp:1256
#24 0x00007fe685b74a0b in QCoreApplication::notifyInternal2(QObject*, QEvent*) (event=0x7fe66810a000, receiver=0x1b0e3d0) at kernel/qcoreapplication.cpp:1090
#25 0x00007fe685b74a0b in QCoreApplication::notifyInternal2(QObject*, QEvent*) (event=<optimized out>, receiver=<optimized out>, this=<optimized out>) at kernel/qcoreapplication.cpp:1076
#26 0x00007fe685b74a0b in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x1b0e3d0, event=event@entry=0x7fe66810a000) at kernel/qcoreapplication.cpp:1015
#27 0x00007fe685b7699c in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (event=0x7fe66810a000, receiver=<optimized out>) at kernel/qcoreapplication.h:225
#28 0x00007fe685b7699c in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x1b0e5e0)
    at kernel/qcoreapplication.cpp:1650
#29 0x00007fe685b76e58 in QCoreApplication::sendPostedEvents(QObject*, int) (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1508
#30 0x00007fe685bca6c3 in postEventSourceDispatch(GSource*, GSourceFunc, gpointer) (s=0x7fe6680012d0) at kernel/qeventdispatcher_glib.cpp:270
#31 0x00007fe6832c1e57 in g_main_context_dispatch (context=0x7fe668000990) at gmain.c:3154
#32 0x00007fe6832c1e57 in g_main_context_dispatch (context=context@entry=0x7fe668000990) at gmain.c:3769
#33 0x00007fe6832c20c0 in g_main_context_iterate (context=context@entry=0x7fe668000990, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
#34 0x00007fe6832c216c in g_main_context_iteration (context=0x7fe668000990, may_block=may_block@entry=1) at gmain.c:3901
#35 0x00007fe685bcaacf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7fe6680008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:417
#36 0x00007fe685b7276a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7fe67caefd00, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#37 0x00007fe6859983b3 in QThread::exec() (this=<optimized out>) at thread/qthread.cpp:500
#38 0x00007fe68599d2d8 in QThreadPrivate::start(void*) (arg=0x1b0e4a0) at thread/qthread_unix.cpp:341
#39 0x00007fe684d93474 in start_thread (arg=0x7fe67caf0700) at pthread_create.c:333
#40 0x00007fe6850913ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Comment 20 Christian Boltz 2016-08-21 15:00:17 UTC 
(copy&paste of my mail to opensuse-factory)

I created a repo with the previous version of libxapian, and akonadi-* 
and baloo linkpac'd from Factory (so rebuilt against the old libxapian):
    https://build.opensuse.org/project/show/home:cboltz:branches:openSUSE:Factory
Packages at
    http://download.opensuse.org/repositories/home:/cboltz:/branches:/openSUSE:/Factory/standard/

Since I installled these packages (using zypper dup --from), I didn't 
see any akonadi crashes.

If someone wants to use the fixed packages _now_: I'll keep the repo 
as long as it's useful for me ;-)


-> this is clearly caused by the libxapian update (libxapian22 -> libxapian30)


BTW: Aitor's backtrace looks like the other backtraces in this bugreport, but without debuginfo packages installed. I've seen something similar before installing the debuginfo packages.
Comment 21 Aitor 2016-08-21 15:03:42 UTC 
More meaningful backtrace (with the missing debug symbols in the previous one) of a following coredump:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `akonadiserver'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  x86_64_fallback_frame_state (context=0x7fd71104c240, context=0x7fd71104c240, fs=0x7fd71104c330) at ./md-unwind-support.h:58
58      ./md-unwind-support.h: No existe el fichero o el directorio.
[Current thread is 1 (Thread 0x7fd71104f700 (LWP 569))]
(gdb) bt
#0  0x00007fd7198b921b in uw_frame_state_for (context=0x7fd71104c240, context=0x7fd71104c240, fs=0x7fd71104c330) at ./md-unwind-support.h:58
#1  0x00007fd7198b921b in uw_frame_state_for (context=context@entry=0x7fd71104c240, fs=fs@entry=0x7fd71104c330) at ../../../libgcc/unwind-dw2.c:1249
#2  0x00007fd7198babb8 in _Unwind_Backtrace (trace=0x7fd7195fd210 <backtrace_helper>, trace_argument=0x7fd71104c4f0) at ../../../libgcc/unwind.inc:290
#3  0x00007fd7195fd37f in __GI___backtrace (array=array@entry=0x7fd71104c5b0, size=size@entry=256) at ../sysdeps/x86_64/backtrace.c:110
#4  0x0000000000574fe6 in akBacktrace() () at /usr/src/debug/akonadi-16.04.3/src/shared/akcrash.cpp:47
#5  0x0000000000575300 in defaultCrashHandler(int) (sig=11) at /usr/src/debug/akonadi-16.04.3/src/shared/akcrash.cpp:91
#6  0x00007fd71953c9f0 in <signal handler called> () at /lib64/libc.so.6
#7  0x0000000000000020 in  ()
#8  0x00007fd6d85445cb in ExternalPostList::ExternalPostList(Xapian::Database const&, Xapian::PostingSource*, double, MultiMatch*) (this=0x7fd6f405c220, db=..., source_=<optimized out>, factor_=<optimized out>, matcher=0x7fd71104dba0) at matcher/externalpostlist.cc:40
#9  0x00007fd6d8456730 in Xapian::Internal::QueryPostingSource::postlist(QueryOptimiser*, double) const (this=<optimized out>, qopt=0x7fd71104d4a0, factor=1) at api/queryinternal.cc:739
#10 0x00007fd6d8454c41 in Xapian::Query::Internal::postlist_sub_or_like(Xapian::Internal::OrContext&, QueryOptimiser*, double) const (this=<optimized out>, ctx=..., qopt=<optimized out>, factor=<optimized out>) at api/queryinternal.cc:626
#11 0x00007fd6d8455f1c in Xapian::Internal::QueryBranch::do_or_like(Xapian::Internal::OrContext&, QueryOptimiser*, double, unsigned int, unsigned long) const (this=this@entry=0x7fd6f4026070, ctx=..., qopt=qopt@entry=0x7fd71104d4a0, factor=factor@entry=1, elite_set_size=elite_set_size@entry=0, first=first@entry=1) at api/queryinternal.cc:1186
#12 0x00007fd6d84564e1 in Xapian::Internal::QueryAndMaybe::postlist(QueryOptimiser*, double) const (this=0x7fd6f4026070, qopt=0x7fd71104d4a0, factor=1) at api/queryinternal.cc:1550
#13 0x00007fd6d854488a in LocalSubMatch::get_postlist(MultiMatch*, unsigned int*) (this=0x7fd6f4047040, matcher=0x7fd71104dba0, total_subqs_ptr=0x7fd71104d60c) at matcher/localsubmatch.cc:204
#14 0x00007fd6d854abb6 in MultiMatch::get_mset(unsigned int, unsigned int, unsigned int, Xapian::MSet&, Xapian::Weight::Internal&, Xapian::MatchDecider const*, Xapian::KeyMaker const*) (this=this@entry=0x7fd71104dba0, first=first@entry=0, maxitems=77512, check_at_least=check_at_least@entry=77512, mset=..., stats=..., mdecider=0x0, sorter=0x0) at matcher/multimatch.cc:419
#15 0x00007fd6d844430f in Xapian::Enquire::Internal::get_mset(unsigned int, unsigned int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) const (this=0x7fd6f40455e0, first=<optimized out>, maxitems=<optimized out>, check_at_least=<optimized out>, check_at_least@entry=0, rset=rset@entry=0x0, mdecider=0x0) at api/omenquire.cc:548
#16 0x00007fd6d8444654 in Xapian::Enquire::get_mset(unsigned int, unsigned int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) const (this=this@entry=0x7fd71104dec0, first=<optimized out>, maxitems=<optimized out>, check_at_least=check_at_least@entry=0, rset=rset@entry=0x0, mdecider=0x0) at api/omenquire.cc:906
#17 0x00007fd6e81bc9bd in Akonadi::Search::XapianSearchStore::exec(Akonadi::Search::Query const&) (this=0x7fd6e00dc8f0, query=...) at /usr/src/debug/akonadi-search-16.04.3/xapian/xapiansearchstore.cpp:177
#18 0x00007fd7101b5cd1 in Akonadi::Search::Query::exec() (this=this@entry=0x7fd71104e130) at /usr/src/debug/akonadi-search-16.04.3/core/query.cpp:252
#19 0x00007fd71064a57a in SearchPlugin::search(QString const&, QList<long long> const&, QStringList const&) (this=<optimized out>, akonadiQuery=..., collections=..., mimeTypes=...)
    at /usr/src/debug/akonadi-search-16.04.3/akonadiplugin/searchplugin.cpp:348
#20 0x000000000055e0c7 in Akonadi::Server::SearchRequest::searchPlugins() (this=this@entry=0x7fd71104e770) at /usr/src/debug/akonadi-16.04.3/src/server/search/searchrequest.cpp:112
#21 0x000000000055e453 in Akonadi::Server::SearchRequest::exec() (this=this@entry=0x7fd71104e770) at /usr/src/debug/akonadi-16.04.3/src/server/search/searchrequest.cpp:123
#22 0x0000000000449487 in Akonadi::Server::SearchManager::updateSearchImpl(Akonadi::Server::Collection const&, QSemaphore*) (this=0x15c34a0, collection=..., cond=<optimized out>)
    at /usr/src/debug/akonadi-16.04.3/src/server/search/searchmanager.cpp:350
#23 0x00007fd71a101cf9 in QObject::event(QEvent*) (this=0x15c34a0, e=<optimized out>) at kernel/qobject.cpp:1256
#24 0x00007fd71a0d3a0b in QCoreApplication::notifyInternal2(QObject*, QEvent*) (event=0x7fd6f4026120, receiver=0x15c34a0) at kernel/qcoreapplication.cpp:1090
#25 0x00007fd71a0d3a0b in QCoreApplication::notifyInternal2(QObject*, QEvent*) (event=<optimized out>, receiver=<optimized out>, this=<optimized out>) at kernel/qcoreapplication.cpp:1076
#26 0x00007fd71a0d3a0b in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x15c34a0, event=event@entry=0x7fd6f4026120) at kernel/qcoreapplication.cpp:1015
#27 0x00007fd71a0d599c in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (event=0x7fd6f4026120, receiver=<optimized out>) at kernel/qcoreapplication.h:225
#28 0x00007fd71a0d599c in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x15c36b0)
    at kernel/qcoreapplication.cpp:1650
#29 0x00007fd71a0d5e58 in QCoreApplication::sendPostedEvents(QObject*, int) (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1508
#30 0x00007fd71a1296c3 in postEventSourceDispatch(GSource*, GSourceFunc, gpointer) (s=0x7fd6f40012d0) at kernel/qeventdispatcher_glib.cpp:270
#31 0x00007fd717820e57 in g_main_context_dispatch (context=0x7fd6f4000990) at gmain.c:3154
#32 0x00007fd717820e57 in g_main_context_dispatch (context=context@entry=0x7fd6f4000990) at gmain.c:3769
#33 0x00007fd7178210c0 in g_main_context_iterate (context=context@entry=0x7fd6f4000990, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
#34 0x00007fd71782116c in g_main_context_iteration (context=0x7fd6f4000990, may_block=may_block@entry=1) at gmain.c:3901
#35 0x00007fd71a129acf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7fd6f40008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:417
#36 0x00007fd71a0d176a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7fd71104ed00, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#37 0x00007fd719ef73b3 in QThread::exec() (this=<optimized out>) at thread/qthread.cpp:500
#38 0x00007fd719efc2d8 in QThreadPrivate::start(void*) (arg=0x15c3570) at thread/qthread_unix.cpp:341
#39 0x00007fd7192f2474 in start_thread (arg=0x7fd71104f700) at pthread_create.c:333
#40 0x00007fd7195f03ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Comment 22 Aitor 2016-08-21 16:44:25 UTC 
Thanks Christian! Your I've just updated my Tumbleweed using your repo and the issue seems to be gone.
Comment 23 kiv 2016-09-07 09:32:28 UTC 
Thanks Christian! 
I also just updated my Tumbleweed using your repo and the issue seems to be gone.
I am crossing fingers in hope this nasty bug could be fixed till the next Tumbleweed update.
Comment 24 Till Schäfer 2016-09-14 11:42:49 UTC 
still valid for 16.08.1
Comment 25 Till Schäfer 2016-09-14 13:19:01 UTC 
i got rid of the crashing by dumping my mysql database and let akonadi create a new one
Comment 26 Till Schäfer 2016-09-14 15:38:15 UTC 
i have re-triggered the bug by the following actions: 
* open Find Message
* entering a search critera and press search
* a message window popped up telling me that the folder is not completely index
* i have pressed re-index folder

after this, akonadi keeps crashing again.
Comment 27 Sandro Knauß 2016-10-07 12:41:34 UTC 
Sounds like a duplicate of #367846
Comment 28 Till Schäfer 2016-10-07 13:29:08 UTC 
*** Bug 367846 has been marked as a duplicate of this bug. ***
Comment 29 Till Schäfer 2016-10-07 13:34:21 UTC 
Interesting detail form Bug 367846:

xapian-check .local/share/akonadi/search_db/emailContacts always crashes with xapian 1.4.x. However, for me, this check even crashes, when akonadi runs fine atop of Xapian 1.4.0 (an no search query folder exist)

-> As Xapian 1.2.x seem to be working with akonadi -> Can someone with Xapian 1.2.x confirm that this crash does not occur?

----------------

$ xapian-check emailContacts/
Cross-checking document lengths between the postlist and termlist tables would use more than 1GB of memory, so skipping that check
docdata:
blocksize=8K items=16458 firstunused=277 revision=913 levels=1 root=22
B-tree checked okay
docdata table structure checked OK

termlist:
blocksize=8K items=16458 firstunused=349 revision=913 levels=1 root=194
B-tree checked okay
xapian-check: Unknown exception
Comment 30 Sandro Knauß 2016-10-09 13:39:51 UTC 
I used xapian 1.2, but xapian-check emailContacts also fails with the same error. For all other xapian collections, this don't fail (calendars/  collections/  contacts/  email/  notes/). But xapian also shows an warning for this collection. And it consumes all free RAm, so it may fail, because it just consume too much RAM? see

Cross-checking document lengths between the postlist and termlist tables would use more than 1GB of memory, so skipping that check

% ldd /usr/bin/xapian-check
        linux-vdso.so.1 (0x00007ffc3ddf6000)
        libxapian.so.22 => /usr/lib/libxapian.so.22 (0x00007f8bac439000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8bac0b8000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8babdb4000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8babb9d000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8bab7ff000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8bab5e2000)
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f8bab3dd000)
        /lib64/ld-linux-x86-64.so.2 (0x000055cb530fc000)

% xapian-check .local/share/baloo/emailContacts
Cross-checking document lengths between the postlist and termlist tables would use more than 1GB of memory, so skipping that check
record:
baseA blocksize=8K items=80571 lastblock=1159 revision=7650 levels=2 root=458
B-tree checked okay
record table structure checked OK

termlist:
baseA blocksize=8K items=80571 lastblock=1345 revision=7650 levels=2 root=415
B-tree checked okay
xapian-check: Unknown exception
xapian-check .local/share/baloo/emailContacts  5,33s user 11,51s system 69% cpu 24,358 total
Comment 31 Daniel Vrátil 2016-10-09 22:53:29 UTC 
Git commit 1e70d63a9439f48b5f1a70accac531a10f4e4239 by Daniel Vrátil.
Committed on 09/10/2016 at 22:52.
Pushed by dvratil into branch 'Applications/16.08'.

Create AgePostingSource on heap

There was an undocumented behaviour change in Xapian 1.4 where
Xapian::Query() no longer internally creates a clone of the
PostingResource that we pass to it and instead takes a (shared)
ownership of the pointer that is then re-used later while
the actual query is being executed, which means that the
PostingResource must live at least until the query execution
is finished.

We were creating the AgePostingSource on stack, which lead to
use-after-free in Xapian 1.4.
FIXED-IN: 5.3.2

M  +1    -2    search/email/emailsearchstore.cpp

http://commits.kde.org/akonadi-search/1e70d63a9439f48b5f1a70accac531a10f4e4239
Comment 32 Olly Betts 2016-10-12 22:28:13 UTC 
> There was an undocumented behaviour change in Xapian 1.4

Otherwise known as a "bug"!  In this case the behaviour change is the bug, but even if it was deliberate not documenting it would still be a bug.

It would be helpful to forwards reports of such things to the Xapian developers so we can actually address them.  In this case I happened to stumble across your report via the Debian BTS when checking for any fallout from the transition to xapian 1.4 that Debian has just completed - clearly that's not a reliable or timely way to find out about an issue.  If this had been forwarded when first reported, we could have fixed it before 1.4.0.

The fix applied in 1e70d63a9439f48b5f1a70accac531a10f4e4239 leaks the AgePostingSource object - with 1.4.0 your best option is to hand over ownership like so:

    return Xapian::Query(Xapian::Query::OP_AND_MAYBE, query, Xapian::Query((new AgePostingSource(0))->release()));

Hopefully there's still a way we can fix this without breaking compatibility with 1.4.0.
Comment 33 Daniel Vrátil 2016-10-13 07:49:58 UTC 
Git commit 5aefe02b83a6d73dbd048337d2ba54fee4bbd67c by Daniel Vrátil.
Committed on 13/10/2016 at 07:49.
Pushed by dvratil into branch 'Applications/16.08'.

Fix a memory leak introduced in 1e70d63a943

M  +1    -1    search/email/emailsearchstore.cpp

http://commits.kde.org/akonadi-search/5aefe02b83a6d73dbd048337d2ba54fee4bbd67c
Comment 34 Olly Betts 2016-10-14 02:28:00 UTC 
I've pushed a fix for this to xapian git master, which I'll backport before 1.4.1:

https://git.xapian.org/?p=xapian;a=commitdiff;h=cef6873ab3849875bf4c5d0147a4a07ba562bad9

With this patch, either the old approach or new approach can be used.