KTcpSocket SslHandshakeFailedError mapping and KIMAP::SessionThread infinite recursion
mbriza at redhat.com
Wed Jun 5 14:21:56 BST 2013
recently there were loads of crash reports for akonadi_imap_resource in
Fedora (seems it was crashing only on x86_64 architecture but this isn't
what I'm writing about).
Basically, what happened:
1) The socket was disconnected by the server side
2) Attempts to reconnect
3) QSslSocket emits error(QAbstractSocket::SslHandshakeFailedError)
4) The error is then mapped to KTcpSocket::UnknownError
(kdelibs/kdecore/network) as no new (Qt 4.4 and on)
QAbstractSocket::SocketError were mapped in the KTcpSocket to any
in the class.
5) SessionThread (kdepimlibs/kimap) in the IMAP resource receives
6) SessionThread tries to disconnect the socket
7) Another error (don't know which one now) gets emitted from QSslSocket,
gets mapped to UnknownError
8) goto 5
?) Stack overflow
The bug is reported in kde#319569 and rhbz#891620. Seems it's happening
only in Fedora (17-19) and Arch Linux currently.
I've fixed (rather "worked around") the problem now in Fedora by checking
if the SessionThread did receive an error signal before receiving this one
and if it did, emitting an error itself instead of trying to disconnect. I
don't think this is really the right solution, especially noticing the
previous problems with race conditions in the class.
My opinion on why this was happening is that there's a problem somewhere
else, like time mismatch, causing the handshake error, which then exposes
What concerns me and what I'm writing about is though the fact the
SslHandshakeFailedError is mapped to UnknownError.
I'm not really familiar with the library but it seems it is quite
important to have this error properly emitted in the KTcpSocket class
because for example the SessionThread in KIMAP intentinally ignores the
Please, is this intentional?
Also, I welcome opinions on the IMAP situation. :)
Thank you in advance,
More information about the kde-core-devel