Bug ID: 369203
           Summary: CollectionFetchJob::exec() hangs forever
           Product: Akonadi
           Version: unspecified
          Platform: Debian testing
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: libakonadi

SyncEvolution uses the blocking API to execute jobs. That used to work fine
with older Akonadi, but on Debian Stretch (= 4.14.10-5) it just hangs. Below is
a stand-alone test program demonstrating the problem.

On Debian Jessie, the output is:
$ ./akonadi-lsDatabase "akonadi" opened using driver "QMYSQL" 

On Debian Stretch:
$ ./akonadi-ls
Shutting down "0x277afc0" ...

Here it got aborted after two hours.

Akonadi seems okay on Debian Stretch:
$ akonadictl status
Akonadi Control: running
Akonadi Server: running
akonadiprivate_log: search paths:  ("lib/x86_64-linux-gnu",
"lib/x86_64-linux-gnu/qt5/plugins/", "lib/x86_64-linux-gnu/kf5/",
"lib/x86_64-linux-gnu/kf5/plugins/", "/usr/lib/qt5/plugins/",
"/usr/lib/x86_64-linux-gnu/qt5/plugins", "/usr/bin")
Akonadi Server Search Support: available (Remote Search)
Available Agent Types: akonadi_akonotes_resource, akonadi_birthdays_resource,
akonadi_contacts_resource, akonadi_davgroupware_resource,
akonadi_googlecalendar_resource, akonadi_googlecontacts_resource,
akonadi_ical_resource, akonadi_icaldir_resource, akonadi_imap_resource,
akonadi_invitations_agent, akonadi_kalarm_dir_resource,
akonadi_kalarm_resource, akonadi_knut_resource, akonadi_kolab_resource,
akonadi_maildir_resource, akonadi_maildispatcher_agent, akonadi_mbox_resource,
akonadi_migration_agent, akonadi_mixedmaildir_resource,
akonadi_newmailnotifier_agent, akonadi_notes_resource,
akonadi_openxchange_resource, akonadi_pop3_resource, akonadi_vcard_resource,

akonadiconsole shows that there are collections.

Reproducible: Always

Steps to Reproduce:
1. cat >akonadi-ls.cpp <<EOF
#include <iostream>
#include <memory>

#include <KApplication>
#include <KAboutData>
#include <KCmdLineArgs>

#include <Akonadi/CollectionFetchJob>
#include <Akonadi/CollectionFetchScope>
#include <QStringList>

using namespace Akonadi;

 * We take over ownership of jobs by storing them in smart pointers
 * (RAII).  This is how SyncEvolution does things and more predictable
 * than assuming that a future exec() call will auto-delete them as
 * part of its event processing.
 * To avoid double frees, we need to disable auto-deletion.
 * This method does that. Use like this:
 * std::auto_ptr<CollectionStatisticsJob> statisticsJob(DisableAutoDelete(new
template<class J> J *DisableAutoDelete(J *job) { job->setAutoDelete(false);
return job; }

int main(int argc, char **argv)
    KAboutData aboutData(// The program name used internally.
                         // The message catalog name
                         // If null, program name is used instead.
                         // A displayable program name string.
                         // The program version string.
                         // Short description of what the app does.
                         ki18n("Lets Akonadi synchronize with a SyncML Peer"),
                         // The license this code is released under
                         // Copyright Statement
                         ki18n("(c) 2010-12"),
                         // Optional text shown in the About box.
                         // Can contain any information desired.
                         // The program homepage string.
                         // The bug report email address

    KCmdLineArgs::init(argc, argv, &aboutData);
    KApplication app(false);

    //  std::unique_ptr<CollectionFetchJob> fetchJob(DisableAutoDelete(new
    // CollectionFetchJob::Recursive)));
    CollectionFetchJob *fetchJob = new CollectionFetchJob(Collection::root(),

    if (!fetchJob->exec()) {
        std::cerr << "Cannot fetch collections." << std::endl;
        return 1;

    Collection::List collections = fetchJob->collections();
    foreach (const Collection &collection, collections) {
        std::cout << << std::endl;
    return 0;
2. g++ -I/usr/include/KDE -I/usr/include/qt4 -I/usr/include/qt4/QtCore -g
akonadi-ls.cpp -o akonadi-ls -lakonadi-kde -lkdecore -lkdeui -lQtCore 
3. ./akonadi-ls

Actual Results:  
It hangs. gdb stacktrace:

(gdb) where
#0  0x00007ffff5cf6080 in __poll_nocancel () at
#1  0x00007ffff1487896 in g_main_context_iterate (priority=<optimized out>,
n_fds=3, fds=0x6c8990, timeout=<optimized out>, context=0x64b370) at
#2  0x00007ffff1487896 in g_main_context_iterate
(context=context@entry=0x64b370, block=block@entry=1,
dispatch=dispatch@entry=1, self=<optimized out>) at ././glib/gmain.c:3922
#3  0x00007ffff14879ac in g_main_context_iteration (context=0x64b370,
may_block=1) at ././glib/gmain.c:3988
#4  0x00007ffff6a10894 in
QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /usr/lib/x86_64-linux-gnu/
#5  0x00007ffff69de82f in
QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /usr/lib/x86_64-linux-gnu/
#6  0x00007ffff69deb95 in
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /usr/lib/x86_64-linux-gnu/
#7  0x00007ffff7527cb3 in KJob::exec() () at /usr/lib/
#8  0x0000000000401823 in main(int, char**) (argc=1, argv=0x7fffffffdec8) at

According to strace, nothing happens anymore at that point.

Expected Results:  
exec() should return.

The environment is the nightly SyncEvolution test setup with manually started
D-Bus daemon and X11 provided by VNC, but users have reported this problem also
in "normal" desktop environments
Ubuntu 15.10 Wily at that time).

You are receiving this mail because:
You are the assignee for the bug.

Reply via email to