Bug 3139 - Main window totally unresponsive due to a busy loop
Summary: Main window totally unresponsive due to a busy loop
Status: VERIFIED FIXED
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: POP3 (show other bugs)
Version: 3.9.3
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
: 2416 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-04-11 20:35 UTC by Aleksander Mazur
Modified: 2014-05-22 19:47 UTC (History)
2 users (show)

See Also:


Attachments

Description Aleksander Mazur 2014-04-11 20:35:28 UTC
I am using claws-mail-3.9.3-1.fc20.i686 and I have a POP3 (TLS) account which locks up the program every time I try to fetch e-mails from it.
After entering password and accepting their certificate GUI locks up totally - no reaction to events, no repainting, 1 CPU core hogged (100%)

The busy loop is at inc.c:858-860.

#0  session_is_running (session=session@entry=0x877c250) at session.c:243
#1  0x080f59c3 in inc_pop3_session_do (session=0x8783388) at inc.c:858
#2  inc_start (inc_dialog=inc_dialog@entry=0x8795670) at inc.c:631
#3  0x080f70b8 in inc_all_account_mail (mainwin=0x84d9ec8, autocheck=1, notify=0) at inc.c:384
#4  0x080f8042 in defer_check_all (data=data@entry=0x1) at main.c:313
#5  0x48066262 in g_timeout_dispatch (source=source@entry=0x86fa738, callback=0x80f8020 <defer_check_all>, user_data=0x1) at gmain.c:4451
#6  0x48065556 in g_main_dispatch (context=0x8497de0) at gmain.c:3066
#7  g_main_context_dispatch (context=context@entry=0x8497de0) at gmain.c:3642
#8  0x48065920 in g_main_context_iterate (context=0x8497de0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713
#9  0x48065dc3 in g_main_loop_run (loop=loop@entry=0x840a7e8) at gmain.c:3907
#10 0x4372d700 in IA__gtk_main () at gtkmain.c:1257
#11 0x080828cf in main (argc=1, argv=0xbffff214) at main.c:1551

Program never goes out of frame #1 above.
The issue is 100%-reproducible.
I tried Thunderbird and it fetches e-emails from that account with no problems.
Workaround: disable problematic account.
Comment 1 Aleksander Mazur 2014-04-11 20:50:19 UTC
Maybe this is related to #2416 but in my case the network log ends with:
Begin TLS negotiation now.
Comment 2 Aleksander Mazur 2014-04-19 08:19:42 UTC
Raising severity since a major feature - fetching e-mails from a POP3 server - doesn't work on a particular account (with 100% reproducibility) while the same e-mail account works fine in Thunderbird.

IMHO there may be 2 bugs here:
- failure to fetch e-mails from POP3 account (busy loop)
- GUI totally locked up by a busy loop in POP3 fetching thread (is this by design?)
Comment 3 Paul 2014-04-19 08:42:43 UTC
lowering severity since it appears to affect you alone
Comment 4 Colin Leroy 2014-04-21 08:20:07 UTC
(In reply to comment #2)

Hi,

> Raising severity since a major feature - fetching e-mails from a POP3 server
> - doesn't work on a particular account (with 100% reproducibility) while the
> same e-mail account works fine in Thunderbird.
> 
> IMHO there may be 2 bugs here:
> - failure to fetch e-mails from POP3 account (busy loop)
> - GUI totally locked up by a busy loop in POP3 fetching thread (is this by
> design?)

POP3 fetching isn't done in a thread, but in GTK's main loop using a state machine.

The busy loop is the real bug. 

Is the server public ? I could investigate if so - apparently having an account wouldn't be needed as the bugs happens on TLS negotiation.

By the way, thanks for your high quality bug reports :)
Comment 5 Aleksander Mazur 2014-04-21 10:34:11 UTC
I reproduced the problem with --debug option. The log (personal data replaced with XXX) ends with:

inputdialog.c:469:return string = ********
inputdialog.c:277:keeping session password for account
inc.c:793:getting new messages of account XXXXXXXXXXX...
session.c:189:session (0x93e7cf0): connected
[09:43:35] POP3< +OK Hello there.
[09:43:35] POP3> STLS
[09:43:36] POP3< +OK Begin SSL/TLS negotiation now.
ssl.c:229:waiting for SSL_connect thread...
ssl.c:247:SSL_connect thread returned 0
ssl_certificate.c:389:got XXXXXXXXXXXXXX.110.cert first try
ssl_certificate.c:236:got cert! 0x9040ee8
ssl_certificate.c:399:got cert 0x88cb848
alertpanel.c:254:Creating alert panel dialog...
alertpanel.c:213:called inc_lock (lock count 1)
alertpanel.c:223:called inc_unlock (lock count 0)
alertpanel.c:107:return value = 1
[09:43:40] POP3> USER XXXXXXXXXXXXXXX

The mail server is public: cba.pl
You're right, it's enough to configure an account in claws-mail using cba.pl, TLS on, "test" username to reproduce the problem (I have just verified it).

However, I'm not sure now if I was really able to fetch e-mails from that server with TLS on in Thunderbird. Possibly I had to switch to plain POP3. And now I am unable to re-check this in Thunderbird because I have already uninstalled it and don't want to install it again :)

Anyway, as you confirmed, busy loop is a problem, so I'd appreciate if you could investigate it...
Comment 6 Michael Rasmussen 2014-04-21 11:03:12 UTC
(In reply to comment #5)
> The mail server is public: cba.pl
> You're right, it's enough to configure an account in claws-mail using
> cba.pl, TLS on, "test" username to reproduce the problem (I have just
> verified it).
> 
Just tried here:
[12:45:15] NNTP< 211 783 6901 7683 dk.edb.system.unix 
* Account 'test': Connecting to POP3 server: cba.pl:995...
[12:45:37] POP3< +OK Hello there.
[12:45:37] POP3> USER mir
[12:45:37] POP3< +OK Password required.
[12:45:37] POP3> PASS ********
[12:45:42] POP3< -ERR Login failed.
*** error occurred on authentication
*** Authentication failed.

No endless loop here.

Using

POP3: Use SSL for POP3 connection
Send (SMTP): Use SSL for SMTP connection

If I shift to use STARTSSL the problems occurs.

However, if I try with IMAP4 instead of POP3 STARTTLS works flawlessly!

To me it seems like a misconfigured server cause the server never returns with an answer to the login request.
Comment 7 users 2014-04-21 11:51:03 UTC
Changes related to this bug have been committed.
Please check latest Git and update the bug accordingly.
You can also get the patch from:
http://git.claws-mail.org/

++ ChangeLog	2014-04-21 13:51:03.507432172 +0200
http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=ea9e88b501a28bb83e32f14c576a0392e82ddbf4
Merge: 88e6033 e664b67
Author: Colin Leroy <colin@colino.net>
Date:   Mon Apr 21 13:51:03 2014 +0200

    Merge branch 'master' of file:///home/git/claws

http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=e664b676602274aa7e7056444de88fa8f5684185
Author: Colin Leroy <colin@colino.net>
Date:   Mon Apr 21 13:49:46 2014 +0200

    Fix bug #3139, "Mainwindow unresponsive due to a busy loop"
    In case of unexpected return from gnutls_record_recv(), set errno to
    a fatal error.
Comment 8 Colin Leroy 2014-04-21 11:57:19 UTC
(In reply to comment #5)

> The mail server is public: cba.pl
> You're right, it's enough to configure an account in claws-mail using
> cba.pl, TLS on, "test" username to reproduce the problem (I have just
> verified it).
>
> Anyway, as you confirmed, busy loop is a problem, so I'd appreciate if you
> could investigate it...

Thanks for the server's name, it helped. Adding a bit of debugging showed that gnutls_record_recv() returns GNUTLS_E_UNEXPECTED_PACKET.

I don't know how to recover from that, but in case of unexpected results from gnutls_record_recv(), I missed setting errno to a fatal error so that the connection would be dropped. 

As it was previously set to EAGAIN by network read code, and gnutls_record_recv() does not set it, it was stuck in an infinite loop.


For the record, gnutls-cli -starttls -p 110 cba.pl fails with:
*** Fatal error: An unexpected TLS packet was received.
*** Server has terminated the connection abnormally.

And openssl s_client -starttls pop3 -host cba.pl -port 110 fails with:
140066369763008:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:

I'll mark the bug fixed as we didn't catch the error, but I guess I can't fix the error itself :)
Comment 9 Michael Rasmussen 2014-04-21 12:33:13 UTC
Strange, suddenly works here with gnutls!!

dpkg -s gnutls-bin
Package: gnutls-bin
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 916
Maintainer: Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>
Architecture: amd64
Multi-Arch: foreign
Source: gnutls28
Version: 3.2.13-2

(In reply to comment #8)
> 
> For the record, gnutls-cli -starttls -p 110 cba.pl fails with:
> *** Fatal error: An unexpected TLS packet was received.
> *** Server has terminated the connection abnormally.
> 
gnutls-cli --starttls -p 110 cba.pl
Processed 166 CA certificate(s).
Resolving 'cba.pl'...
Connecting to '95.211.144.89:110'...

- Simple Client Mode:

+OK Hello there.
user test
+OK Password required.
pass test
-ERR Login failed.
- Peer has closed the GnuTLS connection

> And openssl s_client -starttls pop3 -host cba.pl -port 110 fails with:
> 140066369763008:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
> number:s3_pkt.c:337:
> 
But openssl: 140476822103696:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
Comment 10 Aleksander Mazur 2014-04-27 08:32:02 UTC
No more busy loop when querying this POP3+TLS server in claws-mail a9065aec26499a0e1294c73b6d9e6f039976521e; just a quick error message.

And thanks for discovering that this server supports IMAP+SSL now :)
Comment 11 Colin Leroy 2014-05-22 19:47:56 UTC
*** Bug 2416 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.