KTcpSocket SslHandshakeFailedError mapping and KIMAP::SessionThread infinite recursion

[Martin Briza]

Hi,

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  
errors
	   in the class.
	5) SessionThread (kdepimlibs/kimap) in the IMAP resource receives
	   UnknownError
	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
this bug.

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
sslErrors() signal.

Please, is this intentional?
Also, I welcome opinions on the IMAP situation. :)

Thank you in advance,
Martin