Bug 264622 - kdepimlibs imap/quota crash
Summary: kdepimlibs imap/quota crash
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: IMAP resource (show other bugs)
Version: 4.7
Platform: Arch Linux Linux
: NOR crash
Target Milestone: ---
Assignee: Kevin Ottens
URL:
Keywords:
: 267783 287784 296543 306368 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-01-28 13:22 UTC by David Strobach
Modified: 2012-09-07 00:22 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8


Attachments
fix (1.70 KB, patch)
2011-01-28 13:32 UTC, David Strobach
Details
New crash information added by DrKonqi (9.28 KB, text/plain)
2011-09-05 07:52 UTC, Petr Gebauer
Details
New crash information added by DrKonqi (7.30 KB, text/plain)
2011-09-24 09:06 UTC, Vladimir
Details
New crash information added by DrKonqi (5.50 KB, text/plain)
2011-11-08 20:35 UTC, Lukas Krejci
Details
kdebug output (2.74 KB, application/octet-stream)
2011-11-12 21:27 UTC, Lukas Krejci
Details
kdebug output (2.74 KB, text/plain)
2011-11-12 21:30 UTC, Lukas Krejci
Details
New crash information added by DrKonqi (4.45 KB, text/plain)
2011-11-16 09:17 UTC, Zbynek Kocur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Strobach 2011-01-28 13:22:46 UTC
Application: akonadi_imap_resource (0.1)
KDE Platform Version: 4.6.00 (4.6.0)
Qt Version: 4.7.1
Operating System: Linux 2.6.37-ARCH i686
Distribution: "Arch Linux"

-- Information about the crash:
KIMAP::GetQuotaRootJob crashes if the IMAP server responds with multiple resources per quota root.

example:
C: A003 GETQUOTAROOT INBOX
S: * QUOTAROOT INBOX ""
S: * QUOTA "" (STORAGE 10 512)
S: * QUOTA "" (MESSAGE 300 10000)
S: A003 OK Getquota completed

The crash can be reproduced every time.

-- Backtrace:
Application: Akonadi Resource (akonadi_imap_resource), signal: Segmentation fault
[Current thread is 1 (Thread 0xb4d2c710 (LWP 15965))]

Thread 3 (Thread 0xb28fdb70 (LWP 16022)):
#0  0xb598bd76 in clock_gettime () from /lib/librt.so.1
#1  0xb73fab88 in ?? () from /usr/lib/libQtCore.so.4
#2  0xb74c7a42 in ?? () from /usr/lib/libQtCore.so.4
#3  0xb74c6292 in ?? () from /usr/lib/libQtCore.so.4
#4  0xb74c632d in ?? () from /usr/lib/libQtCore.so.4
#5  0xb58f7096 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0
#6  0xb58f7f33 in ?? () from /usr/lib/libglib-2.0.so.0
#7  0xb58f8604 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#8  0xb74c6ad7 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#9  0xb7498769 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#10 0xb7498a0a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#11 0xb73a1b9b in QThread::exec() () from /usr/lib/libQtCore.so.4
#12 0xb6775d22 in ?? () from /usr/lib/libkimap.so.4
#13 0xb73a4629 in ?? () from /usr/lib/libQtCore.so.4
#14 0xb59f3dd0 in start_thread () from /lib/libpthread.so.0
#15 0xb5b2d89e in clone () from /lib/libc.so.6

Thread 2 (Thread 0xb20fcb70 (LWP 16026)):
#0  0xb78ab424 in __kernel_vsyscall ()
#1  0xb59f86b3 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0xb5b3b514 in pthread_cond_timedwait () from /lib/libc.so.6
#3  0xb73a4c8f in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4
#4  0xb739a5b1 in ?? () from /usr/lib/libQtCore.so.4
#5  0xb73a4629 in ?? () from /usr/lib/libQtCore.so.4
#6  0xb59f3dd0 in start_thread () from /lib/libpthread.so.0
#7  0xb5b2d89e in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb4d2c710 (LWP 15965)):
[KCrash Handler]
#7  0xb678b5dc in KIMAP::GetQuotaRootJob::handleResponse(KIMAP::Message const&) () from /usr/lib/libkimap.so.4
#8  0xb6773c9a in KIMAP::SessionPrivate::responseReceived(KIMAP::Message const&) () from /usr/lib/libkimap.so.4
#9  0xb6774d80 in KIMAP::Session::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libkimap.so.4
#10 0xb749fc0a in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4
#11 0xb74aa306 in QMetaCallEvent::placeMetaCall(QObject*) () from /usr/lib/libQtCore.so.4
#12 0xb74ae87f in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4
#13 0xb69ee844 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#14 0xb69f342e in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#15 0xb6110d0a in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5
#16 0xb749959b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4
#17 0xb749d1c5 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQtCore.so.4
#18 0xb749d39d in QCoreApplication::sendPostedEvents(QObject*, int) () from /usr/lib/libQtCore.so.4
#19 0xb74c6924 in ?? () from /usr/lib/libQtCore.so.4
#20 0xb58f7b72 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#21 0xb58f8350 in ?? () from /usr/lib/libglib-2.0.so.0
#22 0xb58f8604 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#23 0xb74c6a9c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#24 0xb6aa0245 in ?? () from /usr/lib/libQtGui.so.4
#25 0xb7498769 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#26 0xb7498a0a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#27 0xb749d45f in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#28 0xb69ec687 in QApplication::exec() () from /usr/lib/libQtGui.so.4
#29 0xb7786a33 in Akonadi::ResourceBase::init(Akonadi::ResourceBase*) () from /usr/lib/libakonadi-kde.so.4
#30 0x08063b23 in _start ()

Reported using DrKonqi
Comment 1 David Strobach 2011-01-28 13:32:22 UTC
Created attachment 56569 [details]
fix
Comment 2 David Strobach 2011-01-28 13:42:25 UTC
btw, RFC 2087 (IMAP4 QUOTA extension) does not specify the order/number of QUOTA responses.
Comment 3 Thomas McGuire 2011-02-25 12:52:49 UTC
Hi,

thank you very much for your patch! Sorry for the late reply, patches attached to bugs sometimes get overlooked, best is if you use git.reviewboard.kde.org to submit patches, see http://techbase.kde.org/Contribute/Send_Patches#Reviewboard.

It would be really useful if you add a unit test as well, have a look at the existing ones in kimap/tests, they are easy to write.

I told the developer of the quota code about this patch, so he'll have a look soon.
Comment 4 András Manţia 2011-02-25 13:01:48 UTC
Can you please provide an unit test which reproduces the crash and a backtrace with the kimap library compiled in debug mode so it is visible where it crashes?

The patch itself doesn't look bad, but before committing I'd like to see the above (to know what was wrong in the old version). Also if I read the RFC correctly, for one GETQUOTAROOT command multiple QUOTAROOT responses may come (http://www.apps.ietf.org/rfc/rfc2087.html#sec-5.2). In that case here only the last one is taken into account because of the  d->quotas.clear(); I know this was almost also the case before (the root names were lost), but if you work anyway on a patch, you might handle this case as well correctly. :)

Thanks!
Comment 5 Christophe Marin 2011-07-13 10:25:26 UTC
*** Bug 267783 has been marked as a duplicate of this bug. ***
Comment 6 David Strobach 2011-07-13 23:55:54 UTC
Hello,

(In reply to comment #4)
> Can you please provide an unit test which reproduces the crash and a backtrace
> with the kimap library compiled in debug mode so it is visible where it
> crashes?

No, I dont't think more unit tests is what the KDEPIM needs, sorry.

> Also if I read the RFC correctly, for one GETQUOTAROOT command multiple
> QUOTAROOT responses may come

Yes, the QUOTAROOT response example suggests that, but it doesn't make any sense. The QUOTAROOT response carries the name of a mailbox and the list of its quota roots (separated by SPs). I don't see a reason for the response to appear more than once.
Comment 7 András Manţia 2011-07-14 11:54:09 UTC
More unit tests are good. :) Think that someone changes the code and we are back to the same problem. A unit test would catch it.
Comment 8 Petr Gebauer 2011-09-05 07:52:01 UTC
Created attachment 63391 [details]
New crash information added by DrKonqi

akonadi_imap_resource (4.7) on KDE Platform 4.7.00 (4.7.0) using Qt 4.7.3

- What I was doing when the application crashed:

I clicked on just created IMAP resource to show folders.

-- Backtrace (Reduced):
#11 0x00007f9731fb9cef in QList<QByteArray>::operator[] (this=0xd83240, i=14412832) at /usr/include/qt4/QtCore/qlist.h:464
#12 0x00007f9731fe3018 in KIMAP::GetQuotaRootJob::handleResponse (this=<optimized out>, response=...) at /var/tmp/paludis/kde-base-kdepimlibs-4.7.0/work/kdepimlibs-4.7.0/kimap/getquotarootjob.cpp:79
#13 0x00007f9731fd138f in KIMAP::SessionPrivate::responseReceived (this=0xdaacc0, response=...) at /var/tmp/paludis/kde-base-kdepimlibs-4.7.0/work/kdepimlibs-4.7.0/kimap/session.cpp:271
#14 0x00007f9731fd1992 in KIMAP::Session::qt_metacall (this=0xdaab80, _c=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0xdbb7d0) at /var/tmp/paludis/kde-base-kdepimlibs-4.7.0/work/kdepimlibs-4.7.0_build/kimap/session.moc:113
#15 0x00007f9733407c6a in QObject::event (this=0xdaab80, e=<optimized out>) at kernel/qobject.cpp:1217
Comment 9 Vladimir 2011-09-24 09:06:22 UTC
Created attachment 63902 [details]
New crash information added by DrKonqi

akonadi_imap_resource (4.7) on KDE Platform 4.7.1 (4.7.1) using Qt 4.7.2

- What I was doing when the application crashed:
Added an IMAP account imap.atlas.cz. Aconadi then started to check fro e-mails.

- Custom settings of the application:
The crash appears with IMAP accounts on atlas.cz and centrum.cz servers. Possibly others, didn't check.

-- Backtrace (Reduced):
#7  0x0020a2fc in QByteArray (this=0x9d4e0a0, response=...) at /usr/include/qt4/QtCore/qbytearray.h:421
[...]
#9  operator[] (this=0x9d4e0a0, response=...) at /usr/include/qt4/QtCore/qmap.h:531
#10 KIMAP::GetQuotaRootJob::handleResponse (this=0x9d4e0a0, response=...) at ../../kimap/getquotarootjob.cpp:79
#11 0x001f2980 in KIMAP::SessionPrivate::responseReceived (this=0x9ded840, response=...) at ../../kimap/session.cpp:271
#12 0x001f3c88 in KIMAP::Session::qt_metacall (this=0x9c456d8, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x9e01ff0) at ./session.moc:113
Comment 10 Lukas Krejci 2011-11-08 20:35:40 UTC
Created attachment 65411 [details]
New crash information added by DrKonqi

akonadi_imap_resource (4.7) on KDE Platform 4.7.3 (4.7.3) using Qt 4.7.4

- What I was doing when the application crashed:

Added a new imap account on centrum.cz. Imap resource connected successfully but crashed a second later. This is reproducible everytime.

-- Backtrace (Reduced):
#6  0x00007fd9ec648c57 in QByteArray (a=<optimized out>, this=0x7fd9d41ea8e0) at /usr/include/qt4/QtCore/qbytearray.h:421
[...]
#8  operator[] (akey=<optimized out>, this=0x2211e30) at /usr/include/qt4/QtCore/qmap.h:531
#9  KIMAP::GetQuotaRootJob::handleResponse (this=<optimized out>, response=<optimized out>) at ../../kimap/getquotarootjob.cpp:79
#10 0x00007fd9ec632eca in KIMAP::SessionPrivate::responseReceived (this=0x2237100, response=...) at ../../kimap/session.cpp:271
#11 0x00007fd9ec633fa2 in KIMAP::Session::qt_metacall (this=0x2236fc0, _c=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0x22a1320) at ./session.moc:113
Comment 11 Lukas Krejci 2011-11-08 20:47:25 UTC
So there's been a patch for this bug for almost 10 months and the dev says it looks good but doesn't want to apply it because of a missing test?

I mean, guys, it's not like KDE PIM was the stellar example of code maturity.. The thing has been such a headache since 4.0 times.. Yet I've been still hopeful. But seeing the attitude like this I think I start to understand why the progress is glacial..

I wish you guys only the best and really appreciate all you are doing but please this on the border of ridiculous.
Comment 12 András Manţia 2011-11-09 20:51:18 UTC
Just to avoid confusion: it is not that I don't want to rule out the patch completely without a testcase. But a testcase would help to be sure this bug will not return and would explain why the current behavior is wrong.
I wrote above that the RFC suggest a behavior that is different from what the patch introduces.
 I asked for a testcase, the developer of the patch refused it at first, and as I cannot reproduce the bug, I didn't commit it. 
And with time I forgot about it... Unfortunately right now I don't have time to create a testcase myself that reproduce the bug and verify the patch, so help is still welcome.
Comment 13 Lukas Krejci 2011-11-12 21:27:41 UTC
Created attachment 65570 [details]
kdebug output

I am no expert in IMAP or KDEPIM but I hope this could help you.

I checked out kdepimlibs from the v4.7.3 tag and uncommented the debug output of the response in kimap/job.cpp in Job::handleErrorReplies. This I believe gives you an idea of all the responses from the server before the imap resource crashes and maybe figure out what the code fails on and why. If you need any more input from me, let me know what you want me to do and we'll see if I will be able to help you.

Please find the debug output generated in the "kdebug output" attachment.
Comment 14 Lukas Krejci 2011-11-12 21:30:43 UTC
Created attachment 65571 [details]
kdebug output

reattaching as plain text for easier reading
Comment 15 Zbynek Kocur 2011-11-16 09:17:05 UTC
Created attachment 65740 [details]
New crash information added by DrKonqi

akonadi_imap_resource (4.7) on KDE Platform 4.7.3 (4.7.3) using Qt 4.7.4

- What I was doing when the application crashed:

Running kmail application. Checking atlas.cz account.

-- Backtrace (Reduced):
#6  0x00007f0bacf5fa66 in KIMAP::GetQuotaRootJob::handleResponse(KIMAP::Message const&) () from /usr/lib64/libkimap.so.4
#7  0x00007f0bacf49380 in KIMAP::SessionPrivate::responseReceived(KIMAP::Message const&) () from /usr/lib64/libkimap.so.4
#8  0x00007f0bacf4a672 in KIMAP::Session::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib64/libkimap.so.4
#9  0x00007f0bae2daf6a in QObject::event(QEvent*) () from /usr/lib64/qt4/libQtCore.so.4
#10 0x00007f0bad682124 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
Comment 16 David Strobach 2011-11-16 19:20:17 UTC
Hi,

(In reply to comment #11)
> So there's been a patch for this bug for almost 10 months and the dev says it
> looks good but doesn't want to apply it because of a missing test?
> 
> I mean, guys, it's not like KDE PIM was the stellar example of code maturity..
> The thing has been such a headache since 4.0 times.. Yet I've been still
> hopeful. But seeing the attitude like this I think I start to understand why
> the progress is glacial..

I consider this plain insolence - exactly the reason why I refused to write the test.
Comment 17 Kevin Ottens 2011-11-16 19:27:34 UTC
So a "please" followed by a "thanks" is "plain insolence". I see... I'll have to remember it.
Comment 18 David Strobach 2011-11-16 19:59:08 UTC
(In reply to comment #17)
> So a "please" followed by a "thanks" is "plain insolence".

OK, let's be demagogic then. No, of course it's not, but "I wan't merge your patch until you provide a test, beacause I don't want to get dirty." is plain insolence to me.
Comment 19 András Manţia 2011-11-17 06:57:45 UTC
Read that the other way around: I want to *reproduce* the crash before merging a patch that is in somewhat contradiction with the documentation (RFC). The easiest way to reproduce is a test case. The harder way is to give us an account to a problematic server setup.
Nevertheless, I got some information and as soon as I have some time, I will do a test.
Comment 20 Zbynek Kocur 2011-11-17 08:02:30 UTC
(In reply to comment #19)
> Read that the other way around: I want to *reproduce* the crash before merging
> a patch that is in somewhat contradiction with the documentation (RFC). The
> easiest way to reproduce is a test case. The harder way is to give us an
> account to a problematic server setup.
> Nevertheless, I got some information and as soon as I have some time, I will do
> a test.

atlas.cz is a free mail. You can register as new user and test it.

I have this problem at every run of kmail.
Comment 21 András Manţia 2011-11-19 10:08:42 UTC
Git commit 105fc65bf147c1a29660680a8835a6b136311439 by Andras Mantia.
Committed on 19/11/2011 at 11:07.
Pushed by amantia into branch 'master'.

Make GetQuotaRootJob more robust to accept different responses and fix some bugs in it.
Create a unit test for GETQUOTAROOT.
Based on patch by Lukáš Krejčí.

BUGS: 264622
REVIEW: 103150

M  +27   -11   kimap/getquotarootjob.cpp
M  +1    -0    kimap/tests/CMakeLists.txt
A  +187  -0    kimap/tests/quotarootjobtest.cpp     [License: GPL (v2+)]

http://commits.kde.org/kdepimlibs/105fc65bf147c1a29660680a8835a6b136311439
Comment 22 András Manţia 2011-11-19 10:13:25 UTC
Git commit d73681c70eceb0d8f0661e642fdcc9c22e1fcf2a by Andras Mantia.
Committed on 19/11/2011 at 11:07.
Pushed by amantia into branch 'KDE/4.7'.

Make GetQuotaRootJob more robust to accept different responses and fix some bugs in it.
Create a unit test for GETQUOTAROOT.
Based on patch by Lukáš Krejčí.

BUGS: 264622
REVIEW: 103150

M  +27   -11   kimap/getquotarootjob.cpp
M  +1    -0    kimap/tests/CMakeLists.txt
A  +187  -0    kimap/tests/quotarootjobtest.cpp     [License: GPL (v2+)]

http://commits.kde.org/kdepimlibs/d73681c70eceb0d8f0661e642fdcc9c22e1fcf2a
Comment 23 András Manţia 2011-11-19 10:20:28 UTC
Thank you once more for the patches and for the log output. The patch was good, but not complete, I could find some more cases while where kimap behaves wrongly while I created the test for the patch. Hopefully this bug is gone now for everybody.
Comment 24 Myriam Schweingruber 2011-12-05 16:34:10 UTC
*** Bug 287784 has been marked as a duplicate of this bug. ***
Comment 25 Christophe Marin 2012-03-31 13:42:34 UTC
*** Bug 296543 has been marked as a duplicate of this bug. ***
Comment 26 Myriam Schweingruber 2012-09-07 00:21:15 UTC
*** Bug 306368 has been marked as a duplicate of this bug. ***