Application: akonadi_imap_resource (4.14) KDE Platform Version: 4.14.2 (Compiled from sources) Qt Version: 4.8.6 Operating System: Linux 3.16.4-ck2-kubuntu-amdf10-rjvb x86_64 Distribution: Ubuntu 14.04.1 LTS -- Information about the crash: - What I was doing when the application crashed: I had launched kontact for the 1st time after building and installing it from ppa:rjvbertin/kdepim, a PPA holding current-as-of-today git/4.14 builds of kdepimlibs, kdepim and kdepim-runtime, built with clang-3.5 and full optimisation (as far as the CMake build system allows that). NB: only akonadi and the aforementioned packages are built from source. -- Backtrace: Application: RJVB@gmail of type IMAP E-Mail Server (akonadi_imap_resource), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". To enable execution of this file add add-auto-load-safe-path /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20-gdb.py line to your configuration file "/home/bertin/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/bertin/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Current thread is 1 (Thread 0x7f866233f7c0 (LWP 12771))] Thread 3 (Thread 0x7f864e081700 (LWP 12825)): #0 0x00007f865db62c6d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f865cae5fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f865cae60ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007f866194c72e in QEventDispatcherGlib::processEvents (this=0x7f86480008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #4 0x00007f866191a5af in QEventLoop::processEvents (this=this@entry=0x7f864e080e20, flags=...) at kernel/qeventloop.cpp:149 #5 0x00007f866191a8ed in QEventLoop::exec (this=this@entry=0x7f864e080e20, flags=...) at kernel/qeventloop.cpp:204 #6 0x00007f86617fd413 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:538 #7 0x00007f86617ffe03 in QThreadPrivate::start (arg=0x1315940) at thread/qthread_unix.cpp:349 #8 0x00007f865d1ca182 in start_thread (arg=0x7f864e081700) at pthread_create.c:312 #9 0x00007f865db6ffbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7f8647645700 (LWP 12842)): #0 0x00007fffb97e9ff0 in clock_gettime () #1 0x00007f865db7e46d in __GI___clock_gettime (clock_id=<optimized out>, tp=<optimized out>) at ../sysdeps/unix/clock_gettime.c:115 #2 0x00007f866185ee4f in do_gettime (frac=0x7f8647644b80, sec=0x7f8647644b70) at tools/qelapsedtimer_unix.cpp:127 #3 qt_gettime () at tools/qelapsedtimer_unix.cpp:144 #4 0x00007f866194e115 in updateCurrentTime (this=0x7f863c002d30) at kernel/qeventdispatcher_unix.cpp:354 #5 QTimerInfoList::timerWait (this=0x7f863c002d30, tm=...) at kernel/qeventdispatcher_unix.cpp:460 #6 0x00007f866194c5b4 in timerSourcePrepareHelper (src=<optimized out>, timeout=0x7f8647644c54) at kernel/qeventdispatcher_glib.cpp:143 #7 0x00007f866194c68d in timerSourcePrepare (source=<optimized out>, timeout=<optimized out>) at kernel/qeventdispatcher_glib.cpp:176 #8 0x00007f865cae568d in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x00007f865cae5f03 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #10 0x00007f865cae60ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x00007f866194c72e in QEventDispatcherGlib::processEvents (this=0x7f863c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #12 0x00007f866191a5af in QEventLoop::processEvents (this=this@entry=0x7f8647644e20, flags=...) at kernel/qeventloop.cpp:149 #13 0x00007f866191a8ed in QEventLoop::exec (this=this@entry=0x7f8647644e20, flags=...) at kernel/qeventloop.cpp:204 #14 0x00007f86617fd413 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:538 #15 0x00007f86617ffe03 in QThreadPrivate::start (arg=0x12a53a0) at thread/qthread_unix.cpp:349 #16 0x00007f865d1ca182 in start_thread (arg=0x7f8647645700) at pthread_create.c:312 #17 0x00007f865db6ffbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7f866233f7c0 (LWP 12771)): [KCrash Handler] #6 0x00007f865daabbb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #7 0x00007f865daaefc8 in __GI_abort () at abort.c:89 #8 0x00007f86617f4a98 in qt_message_output (msgType=<optimized out>, msgType@entry=QtFatalMsg, buf=0x100fee8 "ASSERT: \"value <= d->end || !hasDefinedEnd()\" in file ../../kimap/imapset.cpp, line 130") at global/qglobal.cpp:2386 #9 0x00007f86617f4e57 in qt_message(QtMsgType, const char *, typedef __va_list_tag __va_list_tag *) (msgType=msgType@entry=QtFatalMsg, msg=0x7f8661985718 "ASSERT: \"%s\" in file %s, line %d", ap=ap@entry=0x7fffb9761508) at global/qglobal.cpp:2432 #10 0x00007f86617f56b4 in qFatal (msg=<optimized out>) at global/qglobal.cpp:2615 #11 0x00007f865f462ae6 in KIMAP::ImapInterval::setBegin (this=0x10b62d8, value=68540) at ../../kimap/imapset.cpp:130 #12 0x0000000000474f02 in BatchFetcher::start (this=0x10b6270) at ../../../resources/imap/batchfetcher.cpp:81 #13 0x000000000044e143 in RetrieveItemsTask::retrieveItems (this=0x129c580, set=..., scope=..., incremental=<optimized out>, uidBased=<optimized out>) at ../../../resources/imap/retrieveitemstask.cpp:477 #14 0x000000000044cd3c in RetrieveItemsTask::onFinalSelectDone (this=0x129c580, job=<optimized out>) at ../../../resources/imap/retrieveitemstask.cpp:424 #15 0x00007f866193195a in QMetaObject::activate (sender=sender@entry=0x10bc970, m=m@entry=0x7f865ea90600 <KJob::staticMetaObject>, local_signal_index=local_signal_index@entry=3, argv=argv@entry=0x7fffb9761a20) at kernel/qobject.cpp:3567 #16 0x00007f865e700912 in KJob::result (this=this@entry=0x10bc970, _t1=_t1@entry=0x10bc970) at ./kjob.moc:207 #17 0x00007f865e700950 in KJob::emitResult (this=0x10bc970) at ../../kdecore/jobs/kjob.cpp:318 #18 0x00007f865f46881b in KIMAP::Job::handleErrorReplies (this=0x10bc970, response=...) at ../../kimap/job.cpp:90 #19 0x00007f865f480969 in KIMAP::SelectJob::handleResponse (this=0x10bc970, response=...) at ../../kimap/selectjob.cpp:174 #20 0x00007f865f4837e6 in KIMAP::SessionPrivate::responseReceived (this=0x1246300, response=...) at ../../kimap/session.cpp:300 #21 0x00007f865f48520d in KIMAP::SessionPrivate::qt_static_metacall (_o=0x1246300, _c=<optimized out>, _id=<optimized out>, _a=0x7f863c02bee0) at ./moc_session_p.cpp:77 #22 0x00007f866193635e in QObject::event (this=0x1246300, e=<optimized out>) at kernel/qobject.cpp:1222 #23 0x00007f8660bd20ac in QApplicationPrivate::notify_helper (this=this@entry=0xf395a0, receiver=receiver@entry=0x1246300, e=e@entry=0x7f863c02d600) at kernel/qapplication.cpp:4570 #24 0x00007f8660bd90c5 in QApplication::notify (this=this@entry=0x7fffb9762640, receiver=receiver@entry=0x1246300, e=e@entry=0x7f863c02d600) at kernel/qapplication.cpp:4356 #25 0x00007f865ecc0cca in KApplication::notify (this=0x7fffb9762640, receiver=0x1246300, event=0x7f863c02d600) at ../../kdeui/kernel/kapplication.cpp:311 #26 0x00007f866191bc04 in QCoreApplication::notifyInternal (this=0x7fffb9762640, receiver=receiver@entry=0x1246300, event=event@entry=0x7f863c02d600) at kernel/qcoreapplication.cpp:953 #27 0x00007f866191f957 in sendEvent (event=0x7f863c02d600, receiver=0x1246300) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231 #28 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, receiver@entry=0x7f866194d060 <postEventSourceDispatch(GSource*, GSourceFunc, gpointer)>, event_type=event_type@entry=0, data=0xef5220) at kernel/qcoreapplication.cpp:1577 #29 0x00007f866191fd07 in QCoreApplication::sendPostedEvents (receiver=0x7f866194d060 <postEventSourceDispatch(GSource*, GSourceFunc, gpointer)>, receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1470 #30 0x00007f866194d073 in sendPostedEvents () at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:236 #31 postEventSourceDispatch (s=0xf25290) at kernel/qeventdispatcher_glib.cpp:287 #32 0x00007f865cae5e04 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #33 0x00007f865cae6048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #34 0x00007f865cae60ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #35 0x00007f866194c70f in QEventDispatcherGlib::processEvents (this=0xf27230, flags=...) at kernel/qeventdispatcher_glib.cpp:434 #36 0x00007f8660c80d86 in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #37 0x00007f866191a5af in QEventLoop::processEvents (this=this@entry=0x7fffb97625d0, flags=...) at kernel/qeventloop.cpp:149 #38 0x00007f866191a8ed in QEventLoop::exec (this=this@entry=0x7fffb97625d0, flags=...) at kernel/qeventloop.cpp:204 #39 0x00007f86619209a9 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1225 #40 0x00007f8661e0aa93 in Akonadi::ResourceBase::init (r=0x1255480) at ../../akonadi/resourcebase.cpp:583 #41 0x0000000000418e87 in Akonadi::ResourceBase::init<ImapResource> (argc=<optimized out>, argv=<optimized out>) at /usr/include/akonadi/resourcebase.h:193 #42 0x00007f865da96ec5 in __libc_start_main (main=0x418e00 <main(int, char**)>, argc=3, argv=0x7fffb9762758, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffb9762748) at libc-start.c:287 #43 0x0000000000418d3c in _start () Reported using DrKonqi
this is the exact assert I was trying to get help with today on #kontact. for me it happens in Fedora20
I don't even understand why the ASSERT is active, because I don't build in debug mode ... Anyway, directly upstream of the failing assert is this: ``` C++ //Prepare next chunk m_searchUidIntervall.setBegin(lastUidToSearch + 1); //Or are we already done? if (m_searchUidIntervall.begin() > m_searchUidIntervall.end()) { ``` where m_searchUidIntervall (with double l???) is the ImapInterval class where things go wrong. I think that the "or are we already done" test can never be true (the condition wouldn't pass the assert and ::end returns 0xFFFFFFFF if no end has been defined). But if it should be possible, then the assert is wrong. However, ImapInterval::setBegin is unchanged from kdepimlibs 4.13.3 so I'm at a loss. As a side note: 0xFFFFFFFF is NOT the maximum value an ImapInterval::Id (qint64) can reach ... (and for a signed int 0x7FFFFFF should have been used) !!
try reverting 94b64eebb6a88846b221aad810045fecb4173f79 in kdepim-runtime/resources/imap I can try that myself tomorrow, but I'm leaving for the day.
What's the official way of doing such a revert?
(In reply to Allen Winter from comment #3) > try reverting 94b64eebb6a88846b221aad810045fecb4173f79 in > kdepim-runtime/resources/imap > > I can try that myself tomorrow, but I'm leaving for the day. Anyway, I think that this is what that patch should have looked like (partly): {{{ // Are we already done? if (lastUidToSearch >= m_searchUidIntervall.end()) { m_searchUidIntervall = KIMAP::ImapInterval(); } else { //Prepare next chunk m_searchUidIntervall.setBegin(lastUidToSearch + 1); } }}}
Seems I was right: https://git.reviewboard.kde.org/r/120967/
didn't http://commits.kde.org/kdepim-runtime/af03ba2ba2390e2f114caa75d0e997900c456359 and http://commits.kde.org/kdepim-runtime/3e159c9e7bbb34301fa3616c9d6f8671a161a9f4 fix the same thing ?
As pointed out by christophe, fixed in af03ba2b.
Yes, I was beaten to it (or would have been if this were a race). In a RR I'd have pointed out that it isn't necessary to use a temp. variable, and that the 1st comment is a little off now, but the purpose is clear. Or so it is when you take the trouble of digging up the original commit message ...
PS: wouldn't it be of interest to know why this issue was triggered on a GMail imap account, which AFAIK no longer provides Exchange features?
(In reply to RJVB from comment #10) > PS: wouldn't it be of interest to know why this issue was triggered on a > GMail imap account, which AFAIK no longer provides Exchange features? The codepath is not exchange specific, it's just that the chunking is not actually used if it's not exchange (one large chunk). It would still hit the error after the first chunk though. The only thing that is a bit strange is that the error should be hit every time, meaning it should have shown up during testing?
I'm not really familiar with IMAP UIDs, but what I gather from the original commit message is that they're not necessarily related to the actual number of messages in a folder. Indeed, it's quite suspicious that the error didn't show every time, and that merits someone having a look to understand why, IMHO (I just don't have the resources right now myself). The only logical explanation I see is that somehow the endpoint didn't get set in cases where the assert didn't fail. That could have been by design, but then the question becomes why I got the abort on something that's not supposed to be an exchange server!